我在一些地方听说分布式版本控制系统闪耀的主要原因之一是比SVN这样的传统工具更好地融合.这实际上是由于两个系统如何工作的固有差异,或者像Git/Mercurial 这样的特定 DVCS实现是否只有比SVN更聪明的合并算法？
我的项目目前正在使用svn存储库,每天可以获得数百个新版本.存储库驻留在Win2k3服务器上,通过Apache/mod_dav_svn提供.
我现在担心,由于修改过多,性能会随着时间的推移而降低.
这种恐惧是否合理？
我们已经计划升级到1.5,因此从长远来看,在一个目录中拥有数千个文件不会成为问题.
Subversion存储了两个版本之间的增量(差异),因此这有助于节省大量空间,特别是如果您只提交代码(文本)而没有二进制文件(图像和文档).
这是否意味着为了检查文件foo.baz的修订版10,svn将采用修订版1然后应用增量2-10？
在我的公司,我们目前正在使用Subversion.我们的项目开发过程包括一个"实时"代码分支(这是我们的实时Web服务器上的内容),一个用于较小项目的通用开发分支,然后每个较大的项目都有自己独立的分支.在任何给定时间,我们通常至少有2个较大的项目正在开发中.将这些合并回实时分支可能会很痛苦,但更重要的是,当大型项目1上线时,大型项目2将在稍后发布,并且合并过程只是......混乱.
我在SVN中一直在做的是每天从开发分支中实时合并(所以发生的任何错误修复等).但是更大的项目合并过程仍然很混乱,我想知道Git是否更干净.作为SVN发生的"坏"事件的一个例子,我们将在dev上有一个小功能,将其合并为live,然后在执行实时反馈时,SVN再次尝试将该功能合并回dev(导致冲突),除非我们在合并中手动取消选择该提交.根据我的理解,Git"聪明"足以知道提交起源于dev,因此它不会尝试将其合并回来......但我的理解可能是错误的.我还听说Git更善于自动处理复杂的合并,就像我们正在努力做的那样.
所以,第一个问题是:Git对于我们正在做的事情是否明显优于SVN,或者我们是否仍然可能遇到同样的问题和刚刚融合的问题？
第二个问题:是否有其他可能更适合我们场景的集成方法？特别是,我正在阅读一篇关于混杂集成的文章,这篇文章似乎很好,尽管看起来似乎也会越多,同时进行的项目也越多.但话说回来,我不希望我们同时拥有超过三个大项目,通常只有两个.持续集成不是我们许多项目的选择,因为它们往往是全有或全无的项目,或者如果被推入部分会对用户产生不利影响(例如我们最近重新设计结账流程). 对于我们的情况,本文似乎也是一种很好的方法.