我最早接触的 SCM 工具是 vss ，但是没用几天（换工作到网易后）就迁移到了 cvs 。我自己大约用了一年后，公司集体从 cvs 迁移到了 svn 。领导这次大迁徙的大大说， svn 是一个更好的 cvs （确实是这样吗？据说有争议，但至少我感觉在多文件版本控制上 svn 比 cvs 方便，因为 cvs 无法保证多个文件同时提交的原子性）。

前几年，有人跟我争论过到底 vss 的加锁模式好，还是 cvs 的合并模式好。我觉得答案是不言而喻的，懒得争论。虽然在某些特殊环境上，我们偶尔需要加锁模式协同工作，但对于程序员的协作来说，无疑我们需要并行的工作。

我们在若干年前曾经淘汰过一次加锁的协作编码方式，而到了今天，是时候再做一些改变了。或许，分布式的版本控制工具才是未来的发展方向。我想，总有一天，cvs/svn 这类集中式版本控制工具会被淘汰掉的。

说说我的困扰吧，可能很多开发小组也遇到过。

1. 我们禁止提交不能编译通过的代码，尽量不提交不能测试通过的代码。结果，对于很复杂的模块，有人几乎一个月都没提交过一次。他总是觉得程序还不太成熟，但几经修改的代码其实从来没有作版本控制。
2. 有些模块由两个人合作编写，关系非常紧凑。有时候需要在两人之间交换一些代码，为了方便，大家通过代码仓库中转，结果在仓库中留下许多未完成的版本。
3. 代码被用笔记本带回家，结果在家完成的部分无处可以提交。（为了安全，我们的代码仓库不能从外网访问）
4. 某人写了一个模块，总是有 bug 没有修改完，而不敢提交。这个时候，另一个人希望协助他找问题，却没有合适的途径 share 那段完成了一半的模块。跑过去 XP 一下么？天哪，为什么我们这里每个人用的编辑器都不一样，还都爱用些特别个性的配色方案呢？

我们尝试过一些 work around 的解决方法，比如在本地自己创建仓库。托 TortoiseSVN 的福，这件事在 Windows 下做起来还是很简单的。可终归是多个仓库的管理，用的人始终感觉麻烦，而没有贯彻下去。

今天有同事问我，分布式版本控制工具到底跟我们现在在用的系统有什么区别。我想了一下回答说：它的本质就是在原有工具的基础上增加了一种方便的仓库合并功能。（哈，我接触这类东西时间不长，大家就当我胡说）

集中式版本控制工具，总要求你有一个中心服务器，提供一个项目仓库。每个人都必须严格保持跟仓库的内容一致。当项目大于等于 2 人时，往往都会指定一些规则，比如不要提交写了一半的代码到仓库去等等。结果，这些规则导致了上面我提到的问题。

即使是一个人自己用，有时候也会碰到问题。有一次我回到家，看到老爸（一个老程序员）在家做一个自己的小东西。因为我们家有两台电脑，我看见两台机器上有若干份不同的版本，我便推荐他用 svn 。因为两台机器都不是 24H 开机，我便选择了在 U 盘上创建仓库。可以设想的到，两台机器的 U 盘插入后盘符是不同的，这可真是一场灾难啊。

其实大多数情况下，我们要的仅仅是 版本管理 ，并不要求通过这类工具协同很多人修改同一份代码。在我们公司，修改别人的代码是要通知文件创建人的。大家都尽量在自己的工作目录下写东西。我并不要求分布式的版本控制工具帮我解决开发人员分布在不同地方的问题，我需要的仅仅是可以更方便的创建私人（或小团体）的分支，可以局部的提交的问题。这些，只需要一个仓库合并的特性就做到了。

我比较孤陋寡闻，知道有分布式版本控制工具是从 git 发布的消息开始的。有 Linus 的鼎鼎大名在那，应该是个好东西。我想还会有一些跟我一样，一进入项目开发就两耳不闻窗外事的朋友，不知道 git 是何物的话，不妨看看 Git 中文教程 。

可惜的是，git 对 Windows 支持的并不好。我们至少还有一半的项目跑在 Windows 下，开发人员则超过一半在用 windows 平台。听说其原因是 git 非常依赖文件系统的一些特性，这些在 Linux 下表现的很好，而 Windows 下特别糟糕。不管具体原因是这个还是别的，我对在公司推广 git 没有多少信心。

另一个选择是 Monotone ，但听说跟 git 有同样的问题（对 windows 的支持问题）。毕竟 git 本身就受了 monotone 的很大影响吧（我猜的）。有趣的是，和 Git 一样 Monotone 也是用 C 写的。当然这句话其实应该倒过来说，因为 Monotone 是从 2003 年开始的，比 Git 早多了。

关于 Git 和 monostone 对 windows 支持不太好的说法，可以参考这一篇： Mozilla: Version Control System Shootout Redux Redux ，Mozilla 的大大这样评价：Git is inappropriate for cross-platform projects due to its UNIX-centric nature; same goes for Monotone.

嗯，既然 Mercurial 是 (Mozilla 的) current favorite (but not the winner) ，我们也可以关注一下。说起来，Mercurial 的命令名很有趣，是 hg 。我花了几秒钟才反应过来，Hg 就是汞嘛 :D 。

下面再让我们看看几个候选人，Bazaar 的网站上有它和其它几种工具的比较。虽然有人说它性能不行，但我想那是针对 Mozllia 这种超级项目说的，我想对我们这样的小东西不会有什么影响。别的方面看起来很不错哟。尤其是它宣称的智能 rename ，真是太有爱了。

svn 下给目录 rename 绝对是场灾难。如果你不小心没有直接去仓库中 rename ，那么就意味着目录下所有文件的 del / add 。而即使你在仓库上直接操作，所有 client 都会大量的做 del / add 操作。每当这个时候，我都超心痛我的硬盘。

darcs 看起来也不错，我对 Haskell 本身就有莫名的好感，用 Haskell 写出来的软件对我就意味着稳定。虽然我自己不怎么玩 Haskell 也不太用 Python ，但是若让我花时间选一门语言玩的话，我会优先试试 Haskell 的。

作为 svn 的老用户，或许应该多关注一下 svk ，它在 svn 的基础上增加了一些分布式管理的东西。但是我不太喜欢这种补丁式的解决方案，因为设计总会随着需求而改变。若是背上太多历史包袱会让我有些不详的预感。

最后可以看看 GNU Arch 。我浏览了 arch 的 wiki 中 WhyArch 这一页，吸引我的是最后两条：

1. Arch is lightweight
2. Arch has a clean and transparent design

不过从 google 搜索结果来看，我没觉得 GNU Arch 是个有前途的项目（相比前面几个而言）。

对于我这样依然有部分时间在 Windows 环境下苟延残喘的程序员来说，有个好消息。那就是托开源的福，可爱的小乌龟无处不在。

1. Mercurial 的乌龟版：TortoiseHg
2. Bazaar 的乌龟版： TortoiseBZR
3. Darcs 的乌龟版： TortoiseDarcs

不过就我的历史经验，只有 TortoiseSVN 是正宗乌龟，最好用。不用对其它版本乌龟的操作手感抱太大希望。

补充：

下面很多朋友谈到，合理的使用 branch 的功能就能解决我碰到的大多数问题。

没错，的确是这样。但是我们现在使用的 svn ，由于各种原因开 branch 都是件很麻烦的事。并不是指操作麻烦，而是管理麻烦。我们没有专门的代码仓库管理人员，大家比较松散。另外，在经过一次安全事故后，公司要求严格控制代码树上每个分支的读写权限。最终导致开 branch 成本过高，而很少有人日常使用。

前面提到分布式版本控制工具提供了方便的仓库合并功能，这个仓库合并其实就是分支合并。并非 svn 没有，而是做的不方便。这一点正如 cvs 的一个老问题：如何方便的确定一组文件的版本，我们可以用 tag 来解决，但终究不如 svn 那样每次多文件提交都是单一原子操作来的方便。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号