我在一些地方听说分布式版本控制系统闪耀的主要原因之一是比SVN这样的传统工具更好地融合.这实际上是由于两个系统如何工作的固有差异,或者像Git/Mercurial 这样的特定 DVCS实现是否只有比SVN更聪明的合并算法？
我已经使用Subversion几年了,在使用SourceSafe之后,我只是喜欢Subversion.结合TortoiseSVN,我无法想象它会如何变得更好.
然而,越来越多的开发人员声称Subversion存在问题,我们应该转向新一代的分布式版本控制系统,例如Git.
Git如何改进Subversion？
我经常读到Hg(和Git和......)在合并方面比SVN更好但是我从未见过Hg/Git可以合并SVN失败的地方(或者SVN需要人工干预的地方)的实际例子.您可以发布一些分支/修改/提交/ ....-操作的逐步列表,显示SVN在Hg/Git愉快地移动时会失败的位置吗？实用,非常特殊的情况请...
一些背景:我们有几十个开发人员在使用SVN进行项目,每个项目(或一组类似项目)都在自己的存储库中.我们知道如何应用发布和功能分支,所以我们不会经常遇到问题(即,我们一直在那里,但我们已经学会克服Joel的问题 "一个程序员给整个团队造成创伤"或"需要六个开发人员两周才能重新整合分支机构").我们的发布分支非常稳定,仅用于应用错误修正.我们的中继线应该足够稳定,能够在一周内创建发布.我们还有一些开发人员或开发人员可以使用的功能分支.是的,它们在重新集成后被删除,因此它们不会使存储库混乱.;)
所以我仍然试图找到Hg/Git优于SVN的优势.我很想获得一些实践经验,但目前还没有任何我们可以移动到汞/ GIT中还没有更大的项目,所以我坚持用只含有少量由文件小型人工玩的项目.而且我正在寻找一些你可以感受到Hg/Git令人印象深刻的力量的案例,因为到目前为止我经常读到它们但却未能自己找到它们.
我听说许多分布式VCS(git,mercurial等)在合并方面比Subversion等传统方式更好.这是什么意思？他们做了什么样的事情才能让合并变得更好？这些事情可以在传统的VCS中完成吗？
奖金问题:SVN 1.5的合并跟踪水平是否适合公平竞争？
我正在寻找可以在git中工作的具体示例合并,但会导致SVN中的冲突.除此之外,您在Git中从未尝试过的艰难/痛苦的SVN合并样本也没问题.
我可以识别出与我的问题相关的四类合并:
我在这里错过了任何场景吗？
找到1-3的样本是微不足道的(在评论中找到2的样本,3作为我的答案的一部分,1几乎是任何rebase).有没有人为一个成功的纵横交叉合并提供样本(看起来不是学术上的),这会在SVN中失败？
我听说过,例如将分支与git或mercurial合并比使用svn更容易.
在软件博客上阅读Joel的最后一篇,我并没有明白为什么.你能提供一个具体的例子,与svn相比,与git/mercurial合并导致更少的合并冲突吗？