分布式版本控制系统合并易用性细节

我刚刚阅读了关于分布式版本控制系统的Joel的blogpost，并且无法理解主要思想。他说，SVN根据版本进行思考，而Mercurial根据变化进行思考。据Joel称，它解决了合并问题。分布式版本控制系统合并易用性细节

我几次听到这个想法，但仍然没有想到它。据我所知，SVN的合并机制也是基于变化（差异）。那么区别是什么呢？我没有使用分布式版本控制系统的经验，但我主动使用SVN分支/合并，并没有出现严重问题。当然，有时会合并冲突（当两个分支中的一段代码被更改时）。但我看不出如何通过某种控制版本系统自动解决这个问题。

来源

2010-06-17 SiberianGuy

不同之处在于现代DVCS记录完整DAG的变化，而afaik svn只记录线性历史记录（或树）并且没有正确记录合并。 – tonfa 2010-06-17 08:41:35

请参阅http://stackoverflow.com/questions/2613525/what-makes-merging-in-dvcs-easy，以及http://stackoverflow.com/questions/2850996/mercurial-vs-subversion-其性能更好/ 2851020＃2851020 – VonC 2010-06-17 09:09:06

乔尔的解释是不正确的。正如Tonfa所说，这里的主要想法是使用现代DVCS中的修订版DAG。 – bialix 2010-06-18 04:49:20

你正在谈论的与SVN的事情是某种树冲突不能由Subversion处理，合并将失败。与git，hg和bzr比较，这是真的，gg，hg或bzr可以处理这些情况。我建议阅读已经完成的bachelor study，当然，其中一些问题已经解决。

来源

2010-06-17 09:15:50 khmarbaise

我会将SVN与Mercurial进行比较，因为这是迄今为止唯一使用的DVCS。 SVN使用文件并为每个下一个版本创建每个文件的副本，而Mercurial组装更改集。您在SVN中拥有完整的文件版本1.0，并且您拥有完整文件版本1.1的另一个副本。在Mercurial中，您在1.0版中拥有完整的文件。然后你有一条规则，例如“在这里添加两行并在那里删除三行”来生成1.1版本。 Mercurial会经历整个历史并在更新过程中将更改应用到本地副本，但它不会存储您的完整文件版本1.1的任何位置。

但是，您描述的问题在Mercurial中也没有技术上解决。我尝试了一个非常简单的例子：让两个人同时在同一个文件的末尾添加一行。第一个承诺并推动没有问题。第二个需要先取得和更新，以便采取最新的变化。这是一个合并冲突，这是令人讨厌的！ Mercurial不知道第二个人是否想添加一行或想修改该行，只是由第一个人添加。它和SVN在这里一样 - 你必须手动合并...所以，没有魔法:)

你可以阅读http://hginit.com/了解更多信息。

来源

2010-06-17 09:28:43

你的答案的第一部分在技术上是不正确的。就像Mercurial一样，SVN只存储差异（“在这里添加2行并删除3行）”。 SVN存储非常高效。这实际上是Mercurial和SVN共同的事情之一。 – 2010-06-17 09:35:52

分布式版本控制系统合并易用性细节

回答

相关问题