三方合并 - 不同的哲学?

Tim*_*ker 4 version-control merge user-interface three-way-merge

自从它首次推出以来,我一直是UltraCompare Pro的用户,我认为它是一个功能齐全的比较和合并工具.但是,由于我一直在密切关注DVCS,我发现它处理三向合并的方式不同于(大多数?)其他工具.所以我想知道为什么会这样,以及我是否因为它而错过了什么.

在UltraCompare中,有三个合并面板(让我们称之为基础,本地和其他).所有合并操作都在这些面板中发生.在实践中,这意味着我在中间窗格(本地)上进行工作,合并来自右侧(其他)的更改,或者可能来自左侧(基础)的共同祖先.中间窗格在会话期间被修改,然后保存 - 并作为合并的结果提交.第四个窗格("输出"窗口)仅包含有关diff结果的信息.

截图UC http://www.ultraedit.com/assets/images/feature_map/uc/three_way_text.png

在其他工具中,似乎三个窗格仅存在于只读状态,而第四个底部窗格(输出)是所有合并发生的位置.有一个额外的合并窗口的原因是什么?是否更容易跟踪所有变化?或者就是这样,因为每个人都一直这样做,所以我们正在复制这种行为?你对此有何看法?

截图kdiff3 http://hginit.com/i/04-kdiff3-after.png

我不确定是否存在最佳或正确答案,所以我还没有提出这个问题CW,但我也会在这里推荐你的意见.

bob*_*nce 6

对我来说似乎很简单,您可能希望在进行更改时保持未更改的"本地"版本.

original       local         other           merged

               bar= foo+1    bar= foo+2      bof= foo+2
                                             zot= foo+1
...            ...           ...             ...
print foo      print bar     print foo+1     print bar??
Run Code Online (Sandbox Code Playgroud)

双方localother引入了新的变量bar.将第一个变化合并到bof/ zot,去喝一杯茶,回来尝试合并print.等待,究竟是什么barlocal?如果原件local不在那里,那些信息就消失了,而你正在用另一个文本编辑器来解决这个问题.

这是一个人为的例子,但是这种事情很容易发生在任何一组变化中,你无法将它们全部放在脑海中并且一气呵成.在一般情况下,一个3WM总是有两个变量因素,改变A和B.更改要重现,所有的信息,你需要的所有可能的排列四点看法:0(原)A,BAB(合并).