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

Question

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

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

Subversion 将版本化树作为一阶对象进行管理（ 存储库是一个树数组），而变更集是 派生（通过比较相邻的树）。像 Arch 或 Bitkeeper 的构建方式正好相反：它们旨在管理 变更集作为一阶对象（存储库是一袋 补丁），树是通过将补丁集组合在一起而派生的。

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

Answer 1

Martin 的博客。这里我就不再重复了。

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

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

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

Answer 2

Git 原则上是以版本树作为一阶对象排列的。也就是说，您处理提交对象的图，每个对象都与作为该修订版本状态的树具有一对一的关系。

请注意，它们的实际存储方式可能非常不同。 Git 一开始只是单独压缩每个文件和树/提交对象。据我了解，将对象打包到单个文件中并仅存储某些对象的增量是很久以后才添加的。

因此，事实上，尽管补丁在 git 用户界面中似乎无处不在，但它们实际上与数据的存储方式无关 - 存储在包文件中的增量是二进制级别的增量，根本不是文本样式的差异。 Git 将应用增量来获取对象，然后再次比较它们以按需生成补丁。这与 CVS 形成鲜明对比，CVS 继承了 RCS 的最新版本加反向增量存储系统。

例如，根据您引用的内容，Git 和 SVN 实际上比 CVS 更相似。

Answer 3

迟到且部分答复。我认为上面没有澄清以下内容：

重要术语：

CVCS = 集中版本控制系统
DVCS = D分布式版本控制系统（由 Git 使用）

REPOSITORY = 项目的文件树，即具有一个或多个子目录的目录，单个项目的所有许多文件。例如：

./Project1/README
./Project1/myprogram.c
./Project1/Makefile
./Project1/images/1.gif
./Project1/images/2.gif

---

集中式：

每个人共享一个（集中式）存储库。

用法：

• 用户检出他们想要编辑的文件（即从远程存储库获取该文件的副本），
• 他们在自己的计算机上本地编辑该文件，然后
• 将文件检回到中央存储库，（即，将其复制回中央存储库，中央存储库记录更改并使更改现在可供其他用户使用）。

更改的权限授予所有用户。

分布式：

每个人共享一个只读存储库，然后在每个用户的位置至少有该存储库的完整副本。

换句话说，每个用户都会将整个项目树的副本复制到其本地计算机上，或从主存储库复制整个文件树。

用法：

• 用户进行本地编辑后，
• 他们可以将编辑提交回中央存储库，以便将其包含在内并与其他人共享。

更改权限由控制主存储库的项目所有者控制。 （在 git 中，我们有一个“拉取请求”，或者向控制中央存储库的项目所有者发出请求，以拉取新的更改。）

我对此进行了过度简化，以重点关注集中式和集中式之间的主要区别分布式。 （现在我承认我仍在学习如何实际记录您所询问的更改，并希望在我完全理解这一点后进行更新。）

参考： 这是一篇很好的更完整的文章。