Knu*_*dna 18 svn git version-control
我已经使用Git一段时间了,并且最近被问到为什么它的合并和分支功能比SVN更好.多年前,当我使用SVN时,我发现分支和合并是非常麻烦且容易出错的操作.结果,我几乎没有分支.然而,就在上周我尝试了新的SVN 1.8版本,我发现它做得非常好.
我实际上尝试了一些复杂的分支,我没有搞笑的错误.当然,它非常缓慢,但我主要关心的是功能,而不是速度(至少在试图说服某人时).
所以我的问题是SVN v1.8和Git分支/合并功能有多大不同.特别是,我也有兴趣知道是否有一些分支和合并操作(或工作流程)可以用Git完成但不能用SVN完成(或者可以用SVN完成,但这很困难).
谢谢.
ran*_*sco 24
了解Subversion合并引擎使用的模型非常重要.它与Git非常不同.
Subversion支持两种基本类型的合并.第一个是"同步"合并,用于使开发(功能/任务/主题)分支与trunk保持同步.第二个是"重新整合"合并,用于促进完成工作到主干.因此,该模型是主线(主干)模型,支持功能分支和发布分支.
一个重要的限制是Subversion在搜索合并历史记录时不考虑完整的DAG以找到正确的合并基础.直接相关(父子)分支之间的合并得到了很好的支持,但是在远离祖先或兄弟姐妹的分支之间进行的合并,其间的贡献来自其他分支,通常会产生令人惊讶的结果.
正如您所指出的,Subversion合并支持正在逐步改进.它在1.5之前根本没有合并跟踪,在1.8中取得了巨大的飞跃,即将到来的1.9将改善重命名/移动跟踪.未来也有关于"本地货架"的讨论.
(顺便说一句,我知道其中一些因为我上周参加了Subversion/Git Live会议,并且合作引擎工作的提交者做了一个演示.)
另一方面,Git拥有备受推崇的合并引擎.它可以处理几乎任何复杂性的合并.事实上,它唯一的主要合并限制是它在事后推断移动/重命名.在非常复杂的重构情况下,它可能无法正常拾取所有内容.
总结一下:
希望有所帮助!