版本控制系统（RCS）的选择与比较

版本控制系统（RCS）的选择与比较

write by 九天雁翎(JTianLing) -- www.jtianling.com

讨论新闻组及文件

为啥考虑选择一个版本控制系统呢？由来已久。其实说到版本控制系统，工作的时候顺从公司的安排，一直用的是VSS，家里面以前常常使用VS，顺便也用上了VSS，但是到了后来，VSS明显不行了，当做Linux的工程，Python工程，或者Eclipse中的工程时，VSS都不太胜任工作，早就想换一个到处能使的版本控制系统了。另外，工作以外其实陆陆续续写了很多代码，在博客上发布的时候常常是用复制粘贴这样的方式，以前也曾经将一些重要的工程打包，放到google groups上去，但是实在是太过麻烦，要方便的话，还是在网站找个项目托管，将所有的代码直接提交，供大家去取的方式最好，顺便将自己的工作之外的代码编写方式统一，也更好组织工程的目录结构。在重装电脑的时候也省事，不用将N大的东西考来考去还怕丢失。在自己家的服务器，台式机，笔记本3者间倒腾代码也更加方便。

       谈谈目前流行的RCS的选择，基本上现在还在用的版本控制系统分为3种，一种以VSS(Visual Source Safe)为代表，在局域网内使用，第二种以CVS(Concurrent Versions System)，SVN(Subversion)为代表在互联网上使用，第三种以Mercurial,Git为代表，以分布式方式使用，（对应的，CVS,SVN的使用方式将所有的内容都集中在一台服务器上，被称作集中式）可以在互联网上使用，但是本机也有代码仓库，可以本地提交代码。基本上，将这三种依次的分为3代也未尝不可。

       Wiki上有个网页很详细的列出了众多流行的RCS极其功能比较，《Comparison of revision control software》，建议所有在众多的RCS软件中看的眼花缭乱的人去看看（也许看过后更加乱了）。总而言之我得出的结论是Mercurial > SVN > CVS > VSS。

       谈谈选择，选择的目的就是在广泛的方位内使用版本控制系统，抛弃VSS本来就是选择的目的，这里就不多说了。

       CVS实在算是老牌的版本控制系统了，当年整个开源世界都是靠CVS过来的。而SVN是CVS开发者特意针对CVS缺点开发的产品，出来以后，整个开源世界都换了颜色。。。。典型的就是Source Forge，这个世界最大的开源站点（个人感觉）都换了SVN后，还有什么理由使用CVS呢？Google Project Host出来的较晚，一开始就是使用SVN。另外，SVN比CVS强大的地方除了上面的WIKI文章，还可以参考本文最后的中文补充材料。SVN替代CVS的趋势是不可逆转的，抛弃CVS。

       现在就剩下SVN,Mercurial,Git了，其实SVN已经足够强大了，这点毋庸置疑，但是为什么我们还需要分布式呢？（Mercurial,Git的代码管理方式）个人工作时的经历，使我决定使用最新的特性。SVN的代码提交必须首先要能联网，这也是开源时，不同的开发者在不同的地方决定的，分布式的好处就是本地也有代码仓库，这样即使没有联网也可以本地提交代码，然后等待联网时再去Merge，当然，这是简单的说明，最大的好处在于，本地也能有一套完整的版本控制系统，在代码没有提交到正式的代码仓库前享受版本控制的好处，这点的好处非常多。举两个最常见的例子，其一就是一个代码量适中的工作，你没有分出版本，工作到一半的时候，很显然不能提交到正式的库里，影响大家的工作，那么中途你想尝试改改代码，有个本地库，能让你更加的自由，其二就是工作已经完成后，但是还没有来得及测试，中途需要去完成一个更加重要的工作，此时代码提交到正式库中还是不恰当的，假如有个本地的库的话，能够先提交，然后无论过了多久后，你再回来，你都能可靠地获取到完整的代码，以前工作的时候在VSS我就碰到过这样的情况，然后1，2天的工作就在一个自以为安全的全取上丢失了。因为上面痛苦的经历，我决定尝试使用最新的分布式版本控制系统，虽然我已经在自己的服务器上好不容易搭建了一套SVN服务了，虽然自己的开发机上都已经装好了TortoiseSVN了，虽然分布式的版本控制系统还太新，以至于还不太完善。呵呵，作为程序员，就要敢于拥抱新事物嘛。。。。。。。。又想起某句名言，IT领域最大的特点就是喜新厌旧。。。。。。

       最后剩下的就是Mercurial和Git之争了，在这两个RCS中选择还真是痛苦的选择，因为各有优势，就像当年选择一个除MFC以外的GUI库一样，Qt与GTK的选择一样痛苦。（当年最后的选择是Qt）这里，有几篇不错的中文文章《拥抱Mercurial---选择分布式版本控制工具》，《分布式版本控制工具：git & mercurial》，《几个分布式vcs比较》(文中的HG就是指Mercurial)对其进行了比较，具体的比较内容这里结合WIKI中的文章总结下：

GIT:

1.   与SVN的集成更好。
2.   GIT是基于内容的跟踪系统，相较Mecurial而言，模型简单些，因此容易扩展；

3.   Linux和rails世界中应用相当广泛。（GIT本身就是Linus开发的，这点是自然的，当年CSDN上C与C++世界最大的口水战不就是因为GIT全部是用C开发，然后某个Windows下的C++开发者提出了疑问后触发的吗。。。。。。）

4.   跨平台特性较弱。（可以理解）

5.   命令复杂。。。。。（对应的也许是功能更加强大吧）

6.   branch建立合并功能强大，方便。

Mercurial：

1. 与SVN命令相似，学习代价更小。

2. 跨平台特性很好。（事实上TortoiseHg较成熟，好用，再加上用Python开发）

3. 使用广泛，文档很好。

4.获得的支持更多。（最典型的就是Google,Google Code原生支持Mercurial）

以下是各自获得的支持列表：

比较明显的是，Git获得的Linux下的支持那是非常多啊。。。。。。

最后，看的越多，越难选择，两者都是非常优秀的软件，相对来说，Git更加强大，但是因为自己还是需要在Windows下做一些工作的，另外，因为想在网上找个地方托管代码，Google支持Mercurial而不支持Git，因为这个缘故，选择Mercurial了。。。。。呵呵，最后的选择因为这么简单的原因。。。。。。。

       另外，对于E文不太好的人，提供一篇中文补充材料：

《版本控制系统简介RCS/CVS/Subversion》向我们讲述了CVS的特性，SVN比CVS强大的地方，以及一些SVN的缺点。

后记：经过使用后，对Mercurial有了一些更理性的认识，相对来说，Mercurial的库的建立因为是分布式的，建立起来更加方便，本地不需要任何服务器什么的，直接就能很好的享受版本控制的好处，仅仅需要了解几个命令就能胜任日常的使用。但是，事实上，目前来说，分布式的如Mercurial的版本控制系统还是有一些缺陷的，最重要的即是权限的控制功能比较弱，这点可能因为Mercurial的用户群主要在于开源世界，所以没有太过重视，实际上企业开发可能会比较恼火，相对来说SVN,特别是VSS就要好的多。然后Mercurial相对Git有个缺点，那就是分支的时候不能对单独的子目录进行，一次clone就是一个工程，这样希望在一个大工程中对一个小项目进行分支，会比较麻烦，这点也算是比较大的缺点了，总的来说，Mercurial还是小项目和小团队使用的版本控制的首选，使用方便，入门也简单，功能强大，但是可能大团队，就得有所考虑了，但是大团队还是想使用Mercurial的话，还是能通过其他版本控制住权限的，然后，通过划分较多小Mercurial项目的版本来解决一次只能分支一个完整Mercurial的问题。

最后，我后来还看到一篇洋洋洒洒的论文-_-!可见事情发生的猛烈和迅速。。。。《为什么软件项目从集中式迁移到分布式版本控制系统的热情持续不减?》
最后的最后，我为Mercurial写了一个简单的介绍及入门引导《分布式的，新一代版本控制系统Mercurial的介绍及简要入门 》

write by 九天雁翎(JTianLing) -- www.jtianling.com

分类:  未分类 
标签:  Git  Mercurial  RCS