svn和git版本化模型的区别

Question

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

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

Subversion mananges将树版本化为一阶对象（存储库是树的数组），并且变更集是派生的东西（通过比较相邻树。）像Arch或Bitkeeper这样的系统是相反构建的：它们被设计为将变更集作为一阶对象（存储库是一包补丁）进行管理，并通过将补丁集合在一起来派生树。

但目前尚不清楚subversion存储库如何存储更改，是否包含版本化文件的最旧版本等等。 例如，为什么我们不能像git一样生成一堆补丁呢？ 它总是被提到作为svn和git之间的主要区别，它简化/复合了合并，但不幸的是，我仍然没有得到这个想法。

Answer 1

关于基于变更集的VCS与Martin博客上的快照之间的主要区别，有一个很好的解释。 我在此不再重复。

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

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

在Subversion中，“合并跟踪”是一种新的东西。 直到版本1.4，没有这样的概念，所以为了了解合并的历史，你必须在你的提交的日志消息中做笔记。 版本1.5实现了合并跟踪，以便更容易地执行从一个分支到另一个分支的重复合并，而不强制用户明确关于修订范围等。 这是通过与接收合并的目录关联的属性（svn：mergeinfo）实现的。 它跟踪哪些修订已经从哪些分支合并。 这足以推断应该在子序列合并中合并哪些修订。 但是，绘制显示合并历史记录的图表并不容易，当您在与多个开发人员的复杂项目中工作时，这是您希望经常看到的内容。

Answer 2

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

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

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

根据你所引用的内容，看起来Git和SVN实际上比CVS更相似，例如。

Answer 3

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

重要条款：

CVCS = C内置版本控制系统
DVCS = D归属版本控制系统（由Git使用）

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

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

---

集中：

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

用法：

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

授予所有用户的权限。

分散式：

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

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

用法：

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

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

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

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