分布式版本控制（完）

本篇作一个简单的总结。

先看一下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提交。