为啥考虑选择一个版本控制系统呢？由来已久。其实说到版本控制系统，工作的时候顺从公司的安排，一直用的是 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 开发者特意针对 SVN 缺点开发的产品，出来以后，整个开源世界都换了颜色。。。。典型的就是 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. 跨平台特性很好。
3. 使用广泛，文档很好。
以下是各自获得的支持列表：
| Stand-alone GUIs | Integration and/or Plug-ins for IDEs | ||
| gitk, git-gui ( Tcl / Tk ), tig, TortoiseGit , qgit, gitg (GNOME/GTK), (h)gct (Qt), git-cola (Qt), Git Extensions (Windows Explorer) | Eclipse ( JGit/EGit ); Netbeans ( NbGit ); Visual Studio ( Git Extensions ); Emacs ( extension for standard VC); TextMate ( Git TextMate Bundle ); Vim (VCSCommand plugin); IntelliJ IDEA >8.1 ( standard feature ); Komodo IDE ; Anjuta | ||
| Hgk (Tcl/Tk), (h)gct (Qt), TortoiseHg (Windows Explorer, Nautilus) | Eclipse ( Mercurial Eclipse ), NetBeans ( [50] ), Visual Studio 2008 ( [51] ), Emacs, Vim (VCSCommand plugin), Komodo IDE |
比较明显的是， Git 获得的 Linux 下的支持那是非常多啊。。。。。。
最后，看的越多，越难选择，两者都是非常优秀的软件，相对来说， Git 更加强大，但是因为自己还是需要在 Windows 下做一些工作的，另外，因为想在网上找个地方托管代码， Google 支持 Mercurial 而不支持 Git ，因为这个缘故，选择 Mercurial 了。。。。。呵呵，最后的选择因为这么简单的原因。。。。。。。
另外，对于 E 文不太好的人，提供一篇中文补充材料：
《 版本控制系统简介 RCS/CVS/Subversion 》向我们讲述了 CVS 的特性， SVN 比 CVS 强大的地方 ，以及一些 SVN 的缺点。
http://blog.csdn.net/vagrxie/archive/2009/09/23/4582457.aspx
扫一扫
297
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
