查看完整版本: 如何处理Baseline时被删除的文件?

如何处理Baseline时被删除的文件?

请教下各位，对于Baseline时，被删除的文件你是怎么处理的。如果做删除操作，在提取老基线时就取不到这个文件了，怎么能解决这问题，或者什么ＣＭ工具解决了这问题？
问题描述如下：
     Baseline1包含３个文件：file_1.c, file_2.c, file_3.c
    Baseline2时只有２个文件：file_1.c, file_3.c
请问该如何处理file_2.c

[[i] 本帖最后由 兰枫 于 2007-12-12 14:58 编辑 [/i]]

可以说下具体的情况么？

比如这3个文件之间的关系？还有就是目前你们的开发模式，比如是几个人分工写代码，这些人负责哪些的模块，只见的关系？还是一个人单独在开发？

我也遇到过类似的，但是不懂得是不是和我的情况类似

是一个人单独开发的模式. 请问shuku你原来是怎么处理这问题的?

愚见

如果只是一个人的话，那在做Baseline2的时候应该就就可以肯定在以后的工作中需要不需要这个file2.c文件了；那建立Baseline2以后，开发人员应该就依据这个Baseline2的基础上来开发，那我觉得就不存在这个file2.c的问题了阿。

如果说你的意思是说提取Baseline1的时候会出现file2.c这个文件，我觉得没有关系阿；Baseline1可以说是Baseline2的一个过程点而已，我们参照了是最终的结果，至于过程的产生我们不管，假如是这样的情况，我在开发过程中，开发到一定阶段，有了一个原始模型，这个时候我建立Baseline1，然后在这个模型的基础上继续开发，在开发的过程中，我发现file2.c是没有必要存在的，可以结合到其他模块当中去，然后我形成了一个相对更加稳定的版本，Baseline2，OK，那我现在接下来要参考的是Baseline2，而不是Baseline1了，所以Baseline1的存在并不影响我后继的工作。

至于我认为Baseline1中的file2.c不需要删除是因为：1、版本管理的工具就必须可以追溯到我历史的纪录；2、开发过程中的不确定性，如果现实情况能按照我上面说的那是最好的，但是往往我们会碰到这样的情况，就是我建立这个Baseline2的时候并不是我说的那个“相对更加稳定的”情况，有时候可能甚至是“处于试验状态的不稳定的状况”，或这“需求的不确定可能带来返工”的情况； 那我们甚至就有必要保存整个开发过程，当然通过基线来建立各个阶段的点，可以更加清楚地做到回溯，不然就要一个一个文件去寻找回溯，那太累，甚至不可能。

所以，你可以把Baseline1当成一个原始的基线，Baselien2可以当成一个稳定状态1，（可能出现稳定状态2，3也不一定）。这样，到了最终我发布这个软件的时候，就会出现最终的软件发布Baseline。是不是感觉这样很舒服？因为任何一个人看到每个阶段的基线就都会很容易明白，没错，一个软件的产生过程出来了，从简单到复杂。

当然，如果你觉得这个file2.c的存在就是个错，那你可以申请变更Baseline1,把file2.c这个文件从Baseline1中删除，然后记得一定要周知项目组。

shuku 再多问一点,

如果在Baseline2时仍然保留File_2.c，那么在配置状态报告中如何处理它？

我担心太多冗余文件会对Building和Release产生影响？

配置状态报告应该只是汇报当前配置库中各个配置项的状态，处于稳定状态还是变更状态，谁在变更，为什么变更，甚至历史变更次数，原因之类的。

那如果你确定需要file2.c就汇报吧；如果你都不需要，已经删除了，那就不需要汇报了。

其实我更想知道，状态统计报告到底要怎么做才能让项目组的人关注到这份报告，感觉这份报告对他们是有帮助的。

两个基线之间文件集合不同很正常

而且，如果BaseLine1取不到某个在BaseLine2中删掉的文件，这才叫不正常

Sorry,我重新检查了贴子,里面有个字打错了,所以会引起误解,应该是在"如果删除file_2.c,在重新提取Baseline1时,就取不到这个文件"

噢，楼主用的什么工具，怎么表示的baseline？

cc可以解决这个问题啊。

你用的什么工具？用Tag的形式来标记Baseline么？你是怎么删除的，在服务器上直接删除么？

如果是用版本管理工具删除，并不会出现你说的情况阿，如果版本管理工具不能纪录历史纪录的话，还要他做什么。我用的是cvs,svn或者Vss 都不会出现这样的情况。

用Vss。在工具中如果用Destroy删除就会出现这样的情况。

基线问题，有待进一步专区讨论~

看得有点迷糊，本人技术和经验知识太肤浅了

２搂的说得不错，大概可以明白意思了！