是什么让Git比Subversion更适合合并？

Question

是什么让Git比Subversion更适合合并？

Bra*_*ery 6 svn git dvcs branching-and-merging

可能重复:
合并:hg/git与svn

我听说/读过Git和DVCS一般比Subversion和集中版本控制系统好.我听到的原因之一是DVCS中的合并比集中式系统好得多.

合并时两者有什么区别？例如,当您重新集成分支时,是什么让Git比Subversion更好？

Answer 1

tda*_*ers 5

事实并非如此,因为它们是分布式的,而是更多的是它们跟踪变更集而不是版本.(但是,分布式系统通常使用变更集,而集中式系统通常使用版本;这是因为分布式系统不能使用基于版本的方法,而集中式系统可以使用它).

Subversion说,好吧,首先我有这个版本然后我有那个版本.然后在合并的时候,它需要两个版本,比较它们,并对如何组合它们做出有根据的猜测.Git,mercurial和类似的SCM,比如说,好吧,首先我没有任何东西,然后有人做了这个改变然后其他人做了这个改变,等等.当它合并时,基本上他们需要做的就是应用正确的改变订购,在这里和那里纠正行号并考虑文件重命名,但基本上就是这样.

Subversion实际上没有足够的信息来执行智能合并:它只看到差异,而不是它们来自何处.

难道Subversion无法遍历修订版以找到相同的信息吗？ (4认同)
好吧,如果Subversion只查看原始文件,然后查看最终结果,它将丢失所有中间步骤,其中DVCS至少使用这些步骤进行合并.但我的问题是为什么Subversion无法分析中间修订以找到这些步骤.我仍然在寻找关于DVCS合并的魔力来自哪里的好解释. (3认同)
@Lasse:当然有.如果不是`r1`和`r2`之间的变化,`r1`和`r2`之间有什么区别？那个论点真的让我感到厌烦. (2认同)
我会买,但后来的争论并不是DVCS在合并时比CVCS好,而是我们通常选择的实现更好.换句话说,Git和Mercurial比Subversion更好,但Subversion*可以*同样好,如果它只是做了不同的事情,但仍然是一个集中的VCS. (2认同)
颠覆中有一些糟糕的设计决策,但它们与集中化并不直接相关. (2认同)

归档时间：	14 年，11 月前
查看次数：	2022 次
最近记录：	14 年，11 月前