Sam*_*eff 13 svn git version-control mercurial dvcs
关于dvcs系统的大量文章声称优越的分支和合并支持是从svn迁移到dvcs系统的一个原因.这些系统究竟如何以不同的方式进行分支和合并以使其更好？
hob*_*bbs 11
从历史上看,git和svn中的合并跟踪之间的区别在于:git具有合并跟踪功能,直到版本1.5,svn没有.完全没有.如果要进行合并,则必须始终准确指定要合并的更改,如果您将一个分支合并到另一个分支中,则必须手动跟踪哪些修订已经合并,但尚未合并,并手动选择尚未合并的更改,以避免冲突.祝你好运,如果你曾挑选任何变化.
从版本1.5(2008年发布)开始,如果您的客户端,服务器和存储库都是最新的,那么svn能够更智能地执行操作; 它使用属性来跟踪分支的来源以及已经合并到其中的更改.结果是,在许多情况下,你可以svn merge BRANCHNAME正确地发生正确的事情.但由于它的"螺栓连接"性质,它仍然不是很快,并不完全健壮.Git的,而另一方面,有处理合并以及由于其性质DVCS场景,并且它从数据结构(如特定类型的DAG它使用)和算法(例如递归合并和octopus-设计之初合并)适合任务.
与普遍认知相反,由于DVCS的分布式特性,与Subversion的集中模型相比,差异并非如此.集中式模型中没有固有的东西需要分支和合并将是不合格的.
我的看法是,Subversion通过决定在单个统一的目录树中建模基于代码库的目录结构,分支和标记(以及所有其他代码管理模式),从而产生了一个巨大的设计失态,这使得可靠地检测分支活动的问题如果分支在模型中是明确的,那么比它的难度高一百倍.
不要忘记任何版本控制系统的人体组件.今天早些时候,我创建并删除了3个不同的本地git分支,因为这是在主分支上完成清理问题的破坏性最小的方法.尝试使用集中版本控制,如果你甚至有权使用它,你很可能会从服务器管理员或愤怒的电子邮件风暴中得到一个演讲.您可以在私人仓库中拥有分支的事实消除了有效使用分支的许多文化障碍.集中式系统使用的算法正在赶上DVCS.那些人为因素将继续存在.
| 归档时间： |
|
| 查看次数： |
1093 次 |
| 最近记录： |