对于上图中的情况, 需要把工作分支BR_***(图片最上面的第一个BR)上的工作合并到主分支上, 熟悉CVS revision规则的都知道, 1.* 的revision号就是主分支. 这里展示的是一个特殊情况, 即因为某种原因(这个原因我在另一篇CVS实践的文章里提过到), 1.26 到 1.27 之间的修改已经被合并到了1.25.2.1 中, 所以, 在再次合并时, 发生了冲突, 我对冲突的解决之道是3方会谈:
1 分叉点版本
2 工作分支最新版本
3 主分支(合并后要提交的目标分支)的最新版本
用文本比较工作打开 1<==>2, 以及1<==3>, 对比参照.
但有时候上面的3方会谈方法不生效, 因为改动的冲突点太多, 靠眼睛盯着来合并, 很难保证不出错. 提前的反向合并(由主分支合并到工作分支)是造成这种情况的主要原因.
对上面这种情况, 我很庆幸当初在提交1.25.2.1 时, 加了注释, 说明这次提交来自对哪两个版本的合并, 直到这时我才注意到, 虽然CVSNT对传统的CVS作了增强, 它可以用紫红线显示出某个版本合并自哪个版本, 但是, 它只能对被合并的两个版本中较靠后者连接, 在此例中, 你可以知道 1.25.2.1 是来自对某一个版本与 1.27 的合并的结果, 但不能通过CVSNT 知道是那"某个版本"到底是哪个, 这个要靠注释来说明.
上面一段是题外话, 我要说的是对于这种情况的合并工作, 要特别注意, 需要同时打开比较的两组文件是
1.25.2.1 <==> 1.25.2.6 (1.25 与 1.25.2.1 之间的不同应该被跳过去, 因为已经被合并过)
1.27 <==> 1.28 (假设在主分支上有这么一个版本)
所需要做的是这两段diff 之间的合并.
阅读(1083) | 评论(0) | 转发(0) |
