alt*_*ern 3 svn git version-control repository
我想知道git(或其他DVCS)和subversion(或其他CVCS)建议的版本控制方法有什么区别.
以下是我在http://www.xsteve.at/prg/vc_svn/svn.txt上找到的有关此主题的内容:
Subversion mananges将树版本化为一阶对象(存储库是树的数组),并且变更集是派生的东西(通过比较相邻树.)像Arch或Bitkeeper这样的系统是相反构建的:它们被设计为将变更集作为一阶对象(存储库是一包补丁)进行管理,并通过将补丁集合在一起来派生树.
但目前尚不清楚subversion存储库如何存储更改,是否包含版本化文件的最旧版本等等.例如,为什么我们不能像git一样生成一堆补丁呢？它总是被提到作为svn和git之间的主要区别,它简化/复合了合并,但不幸的是,我仍然没有得到这个想法.
关于基于变更集的VCS与Martin博客上的快照之间的主要区别,有一个很好的解释.我在此不再重复.
但是,我要强调一点,一开始可能并不明显.基于变更集的VCS使得跟踪合并变得非常容易,对于像Subversion这样基于快照的系统来说这要困难得多.
在基于变更集的VCS中,合并只是具有多个父变更集的变更集(或提交,因为它们在git中调用).存储库的图形表示通常显示DAG(有向无环图),其中节点表示变更集,箭头表示父子关系.当您看到一个包含多个父节点的节点时,您确切知道那里发生了哪种类型的合并.
在Subversion中,"合并跟踪"是一种新的东西.直到版本1.4,没有这样的概念,所以为了了解合并的历史,你必须在你的提交的日志消息中做笔记.版本1.5实现了合并跟踪,以便更容易地执行从一个分支到另一个分支的重复合并,而不强制用户明确关于修订范围等.这是通过与接收合并的目录关联的属性(svn:mergeinfo)实现的.它跟踪哪些修订已经从哪些分支合并.这足以推断应该在子序列合并中合并哪些修订.但是,绘制显示合并历史记录的图表并不容易,当您在与多个开发人员的复杂项目中工作时,这是您希望经常看到的内容.