svn 和 git 版本控制模型的区别

Question

我想知道 git(或其他 DVCS)和 subversion(或其他 CVCS)建议的版本控制方法有什么区别。

这是我在 http://www.xsteve.at/prg/vc_svn/svn.txt 上找到的内容关于这个话题:

Subversion mananges versioned trees as first order objects (the repository is an array of trees), and the changesets are things that are derived (by comparing adjacent trees.) Systems like Arch or Bitkeeper are built the other way around: they're designed to manage changesets as first order objects (the repository is a bag of patches), and trees are derived by composing sets of patches together.

但尚不清楚 subversion 存储库如何存储更改，它是否包含版本控制文件的最旧变体等。例如，为什么我们不能像 git 那样生成一堆补丁？它总是被提及为 svn 和 git 之间的主要区别，它简化/复杂化了 merge ，但不幸的是，我仍然不明白这一点。

Answer 1

在 Martin's blog 上有关于基于变更集和基于快照的 VCS 之间主要区别的很好的解释。 .在此不再赘述。

但是，我要强调一点，一开始可能并不明显。基于变更集的 VCS 使得跟踪 merge 变得非常容易，这对于像 Subversion 这样基于快照的系统来说要困难得多。

在基于变更集的 VCS 中， merge 只是具有多个父变更集的变更集(或提交，因为它们在 git 中被称为)。存储库的图形表示通常显示 DAG(有向无环图)，其中节点代表变更集，箭头代表父子关系。当您看到一个节点有多个父节点时，您就会确切地知道那里发生了哪种 merge 。

在 Subversion 中，“merge 跟踪”是新事物。直到版本 1.4 没有这样的概念，因此为了了解 merge 的历史，您必须在提交的日志消息中做笔记。版本 1.5 实现了 merge 跟踪，以便更容易地执行从一个分支到另一个分支的重复 merge ，而无需强制用户明确说明修订范围等。这是通过与接收 merge 的目录关联的属性 (svn:mergeinfo) 实现的。它跟踪哪些修订已经从哪些分支 merge 。这足以推断在后续 merge 中应该 merge 哪些修订。但是绘制显示 merge 历史的图表并不容易，这是您在与多个开发人员一起处理复杂项目时经常希望看到的东西。