开源点评：源代码版本控制系统介绍

　　本文是“每日构建[4]：相关工具介绍 ”的第一部分。
　　由于源代码版本控制系统（Revision Control System，以下简称RCS）属于“每日构建流程 ”的头一个环节，所以俺在介绍每日构建的相关工具时，先来聊一聊RCS类的软件。<!-- program-think-->

　　★老派的RCS
　　在整个软件开发的生命周期中，RCS处于一个很基础的位置。很多软件工程的环节都会依赖于它。所以，RCS对于整个软件开发过程而言，是非常重要的。但是却有很多软件公司仍然在使用一些比较陈旧落后的RCS。因此，有必要先抨击一下这些老古董的弊端。
　　◇VSS
　　要说老派的RCS，首推微软的Visual Source Safe（简称VSS）。VSS的设计是相当的老土，对源代码库的访问是基于局域网的共享文件夹方式。共享文件夹的方式那是要多土有多土：不光效率低下，而且容易产生安全隐患。
　　光是设计老土也就算了，毕竟人家是九十年代早期设计的，那会儿TCP/IP还没流行呢！VSS还有更严重的问题，就是：误导 了开发人员的对于源代码管理的观念（比如它对文件的锁定模式）。估计有很多开发的新手就是这样被带到沟里去的，以至于长期以来，一直有人在为VSS的锁定模式辩护。
　　当然，VSS还是有少量优点的，比如：捆绑在Visual Studio中，和VS的其它套件整合得比较好。但是这少数优点远远不能抵消它那些严重的缺点。因此俺强烈建议：那些还在用VSS的同学，赶紧换掉吧 ！万一让别人知道你还在用VSS，以后上街都没脸跟人打招呼。如果大伙儿觉得俺说得太夸张，可以去看看牛人Coding Horror写的帖子（在“这里 ”）。

　　◇CVS
　　骂完VSS，再稍微说一下曾经广为流行的CVS，（官方站点在“这里 ”）。
　 　显然，CVS的优点比VSS多多了。想当年，CVS几乎成了源代码版本管理的代名词。那会儿，大部分的开源项目都使用CVS进行代码管理。不过，用的人 多了之后，大家开始发现CVS的一些弊端（比如不能改名文件/目录、比如不支持对目录的版本控制、比如Unicode/UTF8支持不够好、比如版本提交 的原子性、比如......）。
　　有些人受不了CVS的某些缺点，开发了一个改良版的CVSNT 。这玩意儿俺曾经用过几年，比CVS好些，不过几个致命的缺点还在（比如上述提到的改名问题）；还有些人更加激进，干脆另起炉灶，搞出全新的RCS（比如后面提到的SVN，就是为了取代CVS而设计的）。
　　据俺的观察，目前RCS市场的趋势已经比较明显了：很多后来居上的RCS正在逐步侵占CVS的市场份额。长此以往，CVS的人气和份额将会逐年下降。不过它暂时还不会消亡，毕竟还有很多老用户还在用它。
　　所以，俺对CVS的观点是：还在用CVS的同学也可以考虑换一换了。不过捏，假如你暂时不想换，问题也不算太大（至少CVS的问题没VSS那么严重:- ）。

　　★新潮的集中式RCS
　　批完老派的RCS，接着来说说近几年比较时髦的RCS。为了循序渐进，俺先从集中式的RCS说起。
　　在新潮的集中式RCS软件中，SVN（全名叫subversion）是比较有代表性的（官方站点在"这里 "）。俺就重点来说说它。
　　◇SVN的优点
　　其实SVN相对于CVS的优点很多，限于篇幅，俺只挑主要的优点介绍。
　　1、能够导入多种RCS的代码库
　　稍微懂行的人都知道，RCS迁移是一项很严肃的事情，不可等闲视之。如果新的RCS不能很好地导入原有RCS的代码库，那你肯定会死得很难看滴。
　　SVN在这点上是比较成功的：由于它的影响力比较大，自然会有一些第三方的工具提供代码库的导入功能。比如SVN Importer ，可以把其它很多种RCS（比如CVS、PVCS、MKS、ClearCase、SourceSafe）的代码库迁移到SVN。另外还有cvs2svn ，专门用来导入CVS代码库。通过这些工具，你可以完整地保留原有代码库的所有历史版本。
　　2、和CVS的使用类似
　　另外，SVN的一些常用命令、概念、操作习惯都比较类似于CVS（当然，差别还是有的）。比如俺在CVS下经常使用的TortoiseCVS ，也有对应的SVN版本（TortoiseSVN ）。两者就像双胞胎，连界面风格都很像。所以，开发人员从CVS切换到SVN的学习周期会很短，阻力也会很小。
　　3、支持文件/目录改名
　　这个问题一直是CVS的致命伤，SVN没理由不搞定。
　　有了这个功能之后，就可以直接在客户端进行文件的改名操作。拥有新名称的文件，会继承原有文件的版本历史。
　　4、和Web密切整合
　 　这年头，Web越来越成为主流、B/S的操作方式也开始深入人心。SVN迎合了这种趋势，和Apache绑定在一起。由于深度整合了Web，很多版本管 理的操作都可以直接在浏览器上搞定，巨简单的说。另外，Apache作为头号Web Server，功能、性能、安全性自然无可挑剔。
　　5、能很好地整合其它的开发工具
　　得益于SVN的设计理念和开源社区的人气，有越来越多的开发工具都可以和SVN无缝整合。比如在Bug管理方面，有：Trac 、Bugzilla 、Mantis ；至于各种编辑器/IDE的SVN插件，那就更多啦，俺不再一一列举了。

　　◇SVN有些啥缺点
　　1、不支持分布式
　　这是比较明显的缺点。俺后面会提到，集中式相对于分布式具体有哪些缺点。
　　2、性能
　　感觉SVN在性能方面不咋滴，包括操作速度和存储空间，都不太理想。如果和后面提到的分布式RCS相比，这个缺点会更加明显（尤其是在代码commit的时候）。
　　3、到处散落.svn目录
　　其实这个问题倒不是什么大问题（CVS也有此毛病）。或许某些有洁癖的人看着那么多.svn会很不爽。俺自己倒是无所谓。

　　★新潮的分布式RCS
　　◇集中式和分布式的区别
　　分布式RCS和集中式的主要区别在于：
　 　对于集中式RCS，只有一个中央代码仓库，每个开发人员自己机器上维护一个工作拷贝（working copy）。开发人员本地的代码在没有提交之前，是无法被RCS管理的，因此就无法进行各种操作（比如创建分支）。一旦你的开发机器和中央代码仓库的网络 连接断掉（比如你把笔记本带回家写代码），你就只好干瞪眼，无法进行后续工作。
　　对于分布式RCS，每一个开发人员的机器上都有一个代码仓库。你随时都可以提交到本地的代码仓库中。分布式RCS可以在网络连通的时候，再进行各个代码仓库之间的数据同步。
　　为啥这几年，分布式的RCS多起来捏？一个主要的推动力来自于开源社区。大部分开源项目的开发人员都分布在世界各地，有些人受限于网络因素，不能很流畅地和代码仓库交换数据。在这种情况下，分布式RCS的优点就体现出来了。
　　◇哪些公司适合分布式的RCS
　　俺个人认为，一般的软件公司，使用分布式RCS的优点不如开源团队那么明显。但是在如下几种情况，你可以考虑采用分布式RCS。
　　1、开发团队的地域性分隔
　　比如公司的开发团队分散在不同的城市，而且互相之间的网络连接不稳定。这有点类似于开源项目的团队，因此可以考虑采用分布式RCS。
　　2、在公司之外开发
　　所谓的“在公司之外开发”，主要有如下几种情况：比如开发人员喜欢在回家之后干活、比如开发人员经常去客户现场干活、比如公司雇佣兼职人员在家干活。
　　不过这些情况都有一个前提条件，那就是：公司既没有搭建VPN，而RCS又无法从公网上访问。在这种情况下，才值得用分布式RCS。

　　◇几个常见的分布式RCS
　　分布式的RCS，名气比较大的有：Git、Mercurial、Monotone、Bazaar。下面俺大致说一下头两个。
　　1、Git（官方站点在“这里 ”）
　　俺个人感觉，Git的最大亮点和卖点就是：它的创始人是Linus。单凭Linus这个金字招牌，Git就吸引到很多人气。而且Git在各方面的功能还是比较齐全的。
　　它的主要缺点就是对Windows系统支持不太好（想想也是，Linus本人是Linux它爹，对Windows支持不好也在情理之中啊）。不过现在情况略有好转：Windows下的GUI客户端TortoiseGit 才刚出来不久，将来如果能做到像TortoiseSVN 那么成功，那Git在Windows下就前途光明了。
　　Git的成功应用案例，俺不说大伙儿应该猜得到是：Linux Kernel。光这一个就足够说明问题了。
　　2、Mercurial（官方站点在“这里 ”）
　　Mercurial是另一个比较牛的分布式RCS。它还有一个绰号叫Hg。化学比较好的同学，应该会立马联想到：Hg是元素周期表中“水银”的缩写。
　　Mercurial的特色是基于Python开发，所以它在跨平台方面，会比较有优势。另外，它在Windows上的GUI客户端TortoiseHg 也比TortoiseGit 要成熟一些。
　　Mercurial相对于Git的缺点是性能不够好。没准和基于Python开发有关，不过也有可能是Git的性能太过优秀。
　　Mercurial的成功应用案例有：Mozilla、OpenSolaris、NetBeans。这几个也都是重量级的项目。

---

版权声明
本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者编程随想 和本文原始地址：

http://program-think.blogspot.com/2009/06/opensource-review-revision-control.html