分布式版本控制(完)

本篇作一个简单的总结。

先看一下DRCS与传统SCM之间的比较。虽然DRCS有很多优势,但是完全取代集中式的SCM还是不太可能的,毕竟是两个完全不同的思路。

我 曾经乐观地认为DRCS会取代传统SCM,但这只是我个人的体会,我可以很轻松地把SVN换成Mercurial,但是并不表示这对所有人都是合适的。令 狐就指出,在他们公司,因为在VSS的基础上有一整套自己的管理工具和规范,即使明知有更好的选择,也不太可能就把它换掉的。

除了这种情况以外,对于公司模式的开发团队来说,还是需要对源代码有一个集中管理的约束,在这样的情况下,集中式SCM还是大有作为的。

但是对于个人、小团队、分布式团队、特别是开源的开发团队来说,DRCS还是具有传统SCM不可比拟的优势。而且DRCS中的很多优点也是很值得传统SCM借鉴的。比如灵活方便的分支/合并功能。SVN的分支合并功能实在是太弱了,用过的都知道。

再比较一下Bazaar和Mercurial。虽然前几篇中也零散地提到,这里汇总一下。二者在常用功能的操作方面几乎都是秉承传统SCM的操作方式,包括几乎完全相同的操作命令和参数,以及相似的配置文件项目。所以这方面就不说了,只说说二者不同的方面。

Bazaar 的优点是智能重命名,这个在大项目中进行目录重命名时会有优势,但是这个功能毕竟不常用。Mercurial的重命名与传统SCM是一样的,都是删除后重 新添加。在操作性能上Mercurial完胜Bazaar,在安装方便性上也是Mercurial胜出——Bazaar在使用SSH方式进还需要自己安装 额外的依赖软件包。

两种DRCS最大的区别还是在于对远程Repository的操作方面。二者都支持通过HTTP和SSH两种方式访问远程Repository,但实现方式有所不同。

Bazaar的HTTP方式很简单,只要在Web Server里配置一个Directory项目,允许通过HTTP访问Repository中的.bzr目录即可。不过Bazaar的HTTP方式只提供读操作功能,这是它的不足之处。

需 要进行远程Repository的读写操作,还是要用SFTP——FTP over SSH——方式。当然这种访问方式的实现也很简单,只要服务器支持SFTP即可使用。甚至不需要在服务端安装Bazaar,远程Repository的操 作(包括初始创建)也全都是在客户端进行。

Mercurial的情况则要麻烦一些。它的远程Repository操作的前提是必须在服务端安装一个Mercurial,远程Repository也必须在服务端使用init命令创建才可以使用。

首 先是HTTP方式,这需要在服务端运行serve命令,在特定端口上提供HTTP服务,然后由实际的Web Server通过mod_proxy等方式代理一下使用。这样的代价就是需要在服务端消耗额外的资源,但换来的好处是可以提供更强大的功能,而不是像 Bazaar那样只能读访问。

但是Mercurial的SSH方式就有一点不太方便,当然也是因为Windows的缘故,在Linux下还是很方便的。详细的情况参见上一篇。

结论就是没有结论~~冏rz

SVN,Bazaar,Mercurial都很不错,用哪个就看你的实际情况需要了。另,就算是要三个一起用,也不会有什么大的冲突。

个人的推荐是:SVN+任何一个你喜欢的DRCS配合着用是个好办法——用DRCS作小步迭代式的开发,在需要的时候分支或合并,按自己觉得方便的方式(比如固定的周期)进行SVN提交。