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

2009-06-22IT IT.软件介绍 编程 编程.软件工程

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


★老派的 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 管理方面,有:TracBugzillaMantis;至于各种编辑器或 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。这几个也都是重量级的项目。