相关疑难解决方法(0)

我经常读到Hg(和Git和......)在合并方面比SVN更好但是我从未见过Hg/Git可以合并SVN失败的地方(或者SVN需要人工干预的地方)的实际例子.您可以发布一些分支/修改/提交/ ....-操作的逐步列表,显示SVN在Hg/Git愉快地移动时会失败的位置吗？实用,非常特殊的情况请...

一些背景:我们有几十个开发人员在使用SVN进行项目,每个项目(或一组类似项目)都在自己的存储库中.我们知道如何应用发布和功能分支,所以我们不会经常遇到问题(即,我们一直在那里,但我们已经学会克服Joel的问题 "一个程序员给整个团队造成创伤"或"需要六个开发人员两周才能重新整合分支机构").我们的发布分支非常稳定,仅用于应用错误修正.我们的中继线应该足够稳定,能够在一周内创建发布.我们还有一些开发人员或开发人员可以使用的功能分支.是的,它们在重新集成后被删除,因此它们不会使存储库混乱.;)

所以我仍然试图找到Hg/Git优于SVN的优势.我很想获得一些实践经验,但目前还没有任何我们可以移动到汞/ GIT中还没有更大的项目,所以我坚持用只含有少量由文件小型人工玩的项目.而且我正在寻找一些你可以感受到Hg/Git令人印象深刻的力量的案例,因为到目前为止我经常读到它们但却未能自己找到它们.

我在Joel的软件上读到:

使用分布式版本控制,分布式部分实际上不是最有趣的部分.

有趣的是,这些系统考虑的是变化,而不是版本.

在HgInit:

当我们必须合并时,Subversion会尝试查看两个版本 - 我的修改后的代码和修改过的代码 - 它会尝试猜测如何在一个大的邪恶混乱中将它们粉碎在一起.它通常会失败,产生并非真正冲突的"合并冲突"的页面和页面,只是Subversion无法弄清楚我们做了什么的地方.

相比之下,当我们在Mercurial中单独工作时,Mercurial正忙着保留一系列变更集.因此,当我们想要将我们的代码合并在一起时,Mercurial实际上有更多的信息:它知道我们每个人都改变了什么并且可以重新应用这些更改,而不仅仅是查看最终产品并试图猜测如何放置它一起.

通过查看SVN的存储库文件夹,我的印象是Subversion将每个修订版维护为变更集.据我所知,Hg正在使用变更集和快照,而Git纯粹使用快照来存储数据.

如果我的假设是正确的,那么必须有其他方法使DVCS中的合并变得容易.那些是什么？

*更新:

• 我对技术角度更感兴趣,但从非技术角度来看是可以接受的
• 更正:
  1. Git的概念模型纯粹基于快照.快照可以存储为其他快照的差异,只是差异纯粹用于存储优化.- 拉法洛·道格尔德的评论
• 从非技术角度来看:
  1. 它只是文化:如果合并困难,DVCS根本不会工作,因此DVCS开发人员投入大量时间和精力使合并变得容易.CVCS用户OTOH习惯于糟糕的合并,因此开发人员没有动力让它工作.(为什么当你的用户为你的垃圾付出​​同样的代价时能做些好事？)
     ......
     回顾一下:DVCS的重点是拥有许多分散的存储库并不断地来回合并变化.如果没有良好的合并,DVCS根本就没用.然而,CVCS仍然可以通过糟糕的合并来生存,特别是如果供应商可以调整其用户以避免分支.- JörgWMittag的回答
• 从技术角度来看:
  1. 录制真实DAG的历史确实有帮助!我认为主要区别在于CVCS并不总是将合并记录为与几个父母的变更集,从而丢失了一些信息.- tonfa的评论
  2. 因为合并跟踪,以及每个修订都知道其父母的更基本的事实....当每个修订(每次提交),包括合并提交,知道其父项(对于合并提交,意味着拥有/记住多个父项,即合并跟踪),您可以重建图(DAG =直接非循环图)的修订历史.如果您知道修订图,则可以找到要合并的提交的共同祖先.当您的DVCS知道如何找到共同的祖先时,您不需要将其作为参数提供,例如在CVS中.
     .
     请注意,两个(或更多)提交可能有多个共同的祖先.Git利用所谓的"递归"合并策略,它合并了合并基础(共同的祖先),直到你留下一个虚拟/有效的共同祖先(在一些简化中),并且可以做简单的3路合并.- JakubNarębski的回答

检查在Git中合并和/或为什么在SVN中的合并更好？