对，就是最后一个版本创建的日期。

还请赐教，我没做出来

谢谢！

另外提示一点：我用的是日文操作系统，路径带日文的时候就会报错，请大家使用时注意路径问题 ：）

谢谢大家！

得怎么实现呢？

没什么要求，就是把 C:\a 里的内容写到 C:\result.txt 里面

是 a，而不是 a.txt

看看我有多少钱。。。

好东西！

雪儿的方法，历史版本信息会丢失 virtuallife 的方法，在 windows 平台是好用的，版本信息不会丢失，但是 Linux 下就不知道了

laofo，你发生错误的机器是多少位的？ 点击开始，然后在控制面板选项里看看有没有一个 “x86 Control Panel……” 之类的选项？ 如果有，你选一下，里面就有 ClearCase 的选项了。 然后就可以进行 license 的设定了

7788，我不怎么清楚你的描述…… 所以回答也是很模糊，你可以试一下

在机器上实验了一下，没有出现你的现象。。 如果你已经建成了一个 view，那不妨看一下 view 的路径 cleartool lsview -l 然后找一下你的 view 的路径到底在哪里 → 估计不是 D:\views 这个路径

实在不行，你把现在的 view 删掉，重新再建一个 view，再试一下？

有的问题可能是我概念不清，不是很清楚。。。 要是有不对的地方，还请指正 （CMing 的回答的一些补充）

3: clearcase 中触发器的概念倒底是怎么一回事? 什么时候会用到触发器?

我理解的触发器的意义，是对一些操作的限制， 比如新建工程时要加注释，checkin、checkout 时要加注释 打 label 的时候要判定是否符合命名规则等…… 4: clearcase 中有些文件 xiaoxiang 觉得已经是在 CC 控制之下了,可为什么还是要 add to source control 才可以? 我通过 view 已经可以看到这些文件在 vob 里面了呀. 这个你可以看一下文件的类型，如果详细类型还是 view private file 的话，那就是没有 “add to source control” 5: lost+found 目录干啥使的? 打个比方吧，1.c，2.c，3.c 三个文件是有相互关联的关系的。 当 1.c 被删除后，2.c 和 3.c 很可能就一起连带的被删除到了 lost+found 目录里。 6: 一个文件 history 如下 2010-6-2 00:00:00 user1 file-path ............... 2010-6-2 00:00:00 user1 file-path ............... 两条记录时间一样, 用户一样,path 一样. 文件一样, 只是动作不一样, 为什么?(动作并不是指修改之类的,应该是类似与 version XX 之类的) 我也不怎么清楚你说的…… 会不会是同一个文件，名字，路径都一样，但是版本号却不一样？ 要是这样，你可以查一下这两个文件的 uuid，肯定是不一样的。 可能是之前删除后又重新建立，重新 add to source control 里的结果

我按照 7 楼的方法重新做了一次 步骤： 1，新建一个 123 的文件，里面内容为空 2，把 123 checkout，内容改为 111 3，把 123 checkout，然后改名为 234 4，把文件 234 checkin。

我得出的结论： 其实重命名是一个文件的删除和增加的过程（从文件所在的文件夹的 version tree 里可以看出来），而文件本身的版本管理依旧存在。

我刚才在项目的开发环境上做了一下实验，是在本地修改文件，然后提交至服务器，成功了。 步骤： 1，从本地环境连接服务器 2，把本地的文件改名（没有 checkout） 3，改名后，文件会自动有一个 checkin 的过程，这样，新的名字会反应在服务器上。

E:\door\wanghongli_443lj_int\DB_433LJ\硬件设计\电量检测电路@@\main\wanghongli_443lj\1\New Folder

这不是一个版本的信息吧

你把这个，改成 E:\door\wanghongli_443lj_int\DB_433LJ\硬件设计\电量检测电路@@\main\wanghongli_443lj\1 看看能不能成功

make 大人说的对~~~ :victory:

这个，真没有……

在开发环境里也可以看到

利用 version tree,选中 branch,看一下 branch 的相关信息应该也能查到.

板凳也不错 - -!

这次项目规模大..

都是人头,很紧张,满手的汗,再加上服务器出错的状况,就更紧张了,呵呵

还好,2 天的培训都过去了

【论坛 ID】sijishizhe 【申请版块】ClearCase 【职业】ClearCase Admin 以前也做过 CVS admin 【技术专长】没啥专长…… 我活好~

我做的是日本项目，所以对 deliver 的概念不是很明确。 是向服务器提交的过程吗？

如果你的项目里，利用了分支管理，那么在向 main branch 提交的时候，做一个差分 merge 是有必要的，因为做完 merge 后，sub branch 里的东西就能完整的体现到 main branch 里了。 在新建文件的时候也让 merge…… 这个会不会是可选的？ 项目里其他同事也是一样的情况吗？ 新建的时候，add to source control 是正常的。

如果有不对的地方，欢迎指出

有一点，我很赞同 工具好用的时候，大家都很和气，一旦工具不好用的时候，矛头就会从上到下的指向 CM，所以，对问题的事先预见就很重要了 所以，我比较推荐回帖中的事前说明会，让大家看一看，我们想要的理想操作，应该是什么样的。 如果有难度，不能召集全员，那也可以自己录制一个视频，放在公共文件夹上，让大家借鉴。 磨刀不误砍柴工，如果错误的方法一传十，十传百，那就可怕了。

laofu 说的对，当 CM 的意见和项目管理的意见不统一的时候，那不妨大家坐下来谈一谈，商量出一个合适的解决方法，毕竟大家的目的，都是为了这个项目的正常运作，如果自己的力量很小，那就让上面去吵，我们只是照做就可以了。

有的东西，就是秀才遇到兵的感觉，明知道自己是对的，可在 PM 和开发者面前还是感觉很无力

我的项目，是这样做的。（用的是 CC） 在项目正式开发前，准备出一个开发之前的说明书 里面包括了 coding 的方法，和开发工具的使用，还有一些注意事项，在正式开发前，给大家做一个培训 把大家可以做什么，可以怎么做告诉大家，而不是 “开始开发了，就大手一挥：开发吧！ 出了问题再来找我！”

很多问题，在初期意识到了，就是可以避免的， 否则，后期 source 整理的时候，CM 会很辛苦，而且开发者还意识不到是自己的错误。

严重同意 laofu 的看法

作为新人，上来就想让项目按着自己的思路去走，有点不妥，即使他有好的想法，也应该了解团队的背景后，才可以有发言权 这种盲目的意见，不可取。

如果 CVS 已经足够，那为什么要上 CC？ 增加了软件 COST 成本，就不是 SCM 小队能解决的问题了。。

[[i] 本帖最后由 sijishizhe 于 2009-12-24 14:30 编辑 ]

其实，本身就是一拉风的爷们，哈哈！

我认为，这样是不合理的，随便的创建分支，删除分支本身就是危险的。分支里的内容一旦删除，本地又没有备份，那开发人员就悲剧了。 回答： 1 不合理 开发人员的改进是一方面，项目管理本身也是有问题存在的，不能让开发人员自己建立 branch 2 会带来问题 数据丢失，版本丢失，或者不完全 3 从管理方面进行约束 可以建立 branch，但不能私自删除 4 项目初期，就在 source 里创建分支，大家都在分支里作业，等 source 成型了，就向 main branch 上进行 merge 操作 * 注意，这是项目的强制规定，初期的时候就要执行

个人意见，来自大连城管~

可怜的小菜鸟……

一个健全的项目，一定要有相应的品质管理，变更管理，和问题管理的相关存在。前提是，当项目稳定后，有管理人员发现初期的忙碌后，CM 进入了一种空闲状态，于是以上的案例就出现了。。

作为 “小菜鸟”，应该怎么做呢？

如果是我，就选择两者兼顾。 可能是不够专一吧，但初期的构建已经过去，中期主要的就是维护正常运作的任务了，所以，兼职 QA 也是可以的，不仅拓宽下知识，而且还能知道大家平时哪里容易出现问题，在 CM 方面哪里需要格外注意防止大家的误操作……

这样，又有实际案例，又有维护经验，何乐而不为呢？

个人见解，来自大连城管 ：）