用VSS，两个开发人员同时要修改一个代码文件，此时应该怎么办？
作者 nicole_zmf   查看 1268   发表时间 2008/8/5 11:18  【论坛浏览】
用VSS，有一种常见情况就是可能两个开发人员同时要修改一个代码文件，但是实际上遇到这种情况往往就是一个开发人员先进行修改（VSS只能保证在某一时间内只有一个签出），改好后另一个开发人员再进行修改。如果另一个开发人员，为了不影响其工作，在本地上进行修改，在签入时可能就会造成代码的版本被覆盖掉，不知道大家遇到这样的情况是怎么做的，有没有好的建议可以提供参考呢？

序号 评论者 共有评论 10   【论坛浏览】  【发表评论】 评论时间
1 wwalex 需要做到迁出后才能修改，就没这样的问题了 2008/8/5 11:29
2 nicole_zmf 回复 沙发 的帖子
如果这样，另一个开发人员就只能等前面的开发人员先行修改之后再修改了。		 2008/8/5 14:57
3 wangwen 最新版本vss 支持像cvs svn的多人checkout ，合并，这些操作
不过不是默认的 需要设置
btw 实在不行手动合并 合并！！！！不是check in！！！		 2008/8/5 15:37
4 hongerchen wangwen说得对，VSS2005是支持多人Check Out的，如图。

但是无论是一个一个checkout，还是多人checkout，楼主的问题都不可避免的遇到合并的问题。都需要人为地合并版本。

因此，及时我们像楼主不改变任何VSS的设置。只要指定一个有效的管理策略即可，即
1、需要修改代码的时候，方可check out代码
2、修改完成后，及时check in代码
3、如遇在他人check out代码时也需要修改代码，get最新版本，在本地修改，等他人check in之后，check out 并合并版本，check in

点击查看大图

 2008/8/6 17:35
5 nicole_zmf :9:: 多谢楼上两位的建议，我们使用的是６.0的．ＶＳＳ6.0试过应该也是支持多人签出的，我只是试过两个人的．但就像两位说那样最后合并是总是要做的，需要最后一个改代码的人手动去选择来决定的．CVS用的不多，但据了解应该是自动合并的吧，有问题报冲突．这里先问一下VSS2005最后的合并是自动的还是需要手动调整的？
我们这种现象出现的比较特殊，我们并没有启用多人签出这一项，主要是担心，多人签出改来改去然后再手工合并公比较麻烦，就一直采用只允许一人签出．这种情况下就出现问题了,先来说一下我们的代码是怎么被覆盖的，操作步骤如下：
1．两个人GET一个目录下的文件.
2．现以一个人先行在ＶＳＳ签出，另一个人先在本地改为例．甲要修改的文件是:A，B（在VSS中修改A）;乙要修改的Ａ，Ｃ(在本机上修改A)
3.甲修改A后签入，又去修改B,同样改后签入(此时乙本机修改A,还没有修改完)。
4.乙在本机上继续修改A,本机改好后打算往VSS中签入（注：此时乙的操作是把这一整个目录下的代码都签出了，而且没有再次获取最新），当乙打算签入本机A时，因为本机上与VSS中代码是不一致的。ＶＳＳ会给出两种提示：一是保留ＶＳＳ库中的文件，二是用本地文件替换代码文件，此时，选择第二项乙的代码就是最新的版本了。
可是经过乙这样的操作，原来甲修改的两个代码文件A,B就都被覆盖了．
描述的可能有点乱，不知道大家有没有理解．．．．．；7
其实这样的问题也是偶尔出现，也是乙对ＶＳＳ的操作不正规，但做为配置管理员来讲也应该采取一定的办法减少这种现象的发生的呀．我还太不了解，如果大家遇到这种情况应该怎么做的，能不能提供一些办法参考？		 2008/8/7 22:27
6 hongerchen 事情到这个份上，主要问题出现在乙身上。

当乙自行在本机修改A后，需要把修改的东西Checkin时，首先做的一个操作应该是Checkout A，这是VSS会提示服务器上和本地版本有差异，他有责任对比服务器和本地的版本，合并后再check in。

有个观点我想说明一下：无论是VSS还是CVS，还是ClearCase，所谓的自动合并，都是虚假的。试想，如果都自动了，拿张三和李四，各自写各自代码，放到配置库中，配置管理工具就自己做合并集成了。所以自动合并，也只是弄了一个工具和机制，识别出来改动是什么（文本文件好比较一些，其他文件需要专业工具进行比较）。配置管理工具借助这种工具和机制来达到提醒用户的目的，最终还是得用户去修改代码，进行合并。		 2008/8/8 13:49
7 wangwen 首先，所有的修改必须在Checkout的情况下进行，补允许get修改
其次，如果开发人员不遵守规则，则关闭其他人的写权限要求所有的代码修改必须提交申请，然后由admin提供代码的最新版本给开发人员。
再次，如果你想自己省事，就要求每次提交都要有开发人员leader的diff报告，要求leader进行diff审查后确认该提交的版本为正确代码方可提交，凡是没有leader认可（必须要有书面的签字认可！！！防止事后不认账）的提交均视为非法提交，按照不遵守公司规定上报上级处理		 2008/8/21 15:59
8 wenleili wangwen说的第一点，固然很重要，但是实际操作中，大家不全是按照此操作，而且也没有很好的机制可以监督，只有当他们提交覆盖别人的代码时，需要配置管理员找回版本时，我们才知道，平时只要他们提交没出错，你也不知道他们是不是get到本地修改。既然不能避免，干脆我就跟他们说在本地修改时，怎样避免覆盖别人的代码。
开发人员有时会问我这个问题，我们也是同一时间只允许一个人修改，但是别人总不能干等啊！
如果多人要修改同一文件时，我给的建议是，假设A,B,C三个人，他们现在取配置库此文件的最新版本。
由A在配置库Check Out修改，B将取下的文件移到本地别的目录修改，不在设置的本地路径下修改此文件，C和B一样。此时A修改完，将文件Check In，B此时A提交后的文件Check Out，对比自己在另一目录下修改的文件，对比有何不同，将自己修改的部分贴上去，将文件Check In，C再将最新的文件Check Out，之后操作和B差不多。		 2008/8/22 13:48
9 wangwen 第一点
我们的做法是，修改之前必须checkout
checkout视为你开始该工作的标识
按照日程今天你应该修改XXX代码，可是你一天都没有checkout它
好了 你等死吧 今天至少要你加班几个小时写报告材料，来解释为什么你会在瞬间修改完成大量的代码

另外如果你们总是并行修改还是把多人checkout打开吧		 2008/8/26 16:58
10 wangwen 另外 leader的diff报告就是一个好的监管机制。当你要为别人的过错负责时，你就会严格的监督那个人 2008/8/26 17:00
 共有评论数 10  每页显示 10
页码 1/1  |<  <<   1   >>  >|