git and subversion

Linus 在 Google 做了他对于版本控制软件的演讲。他似乎非常偏爱分布式版本控制软件，否则宁愿用 tarball+patch (其时 tarball+patch 确确实实是一种分布式的方法呢！)。以至于在 Linux 内核不能试用 BitKeeper 以后，他自己动手写了 git 。他对版本控制软件有许多要求，比如：

1. 取出来的东西要和放进去的东西一样。如果连数据的完整性都无法保证的话，谁还敢用这样的版本控制软件？不过确实有这样的软件存在呢。
2. 分布式。我在后面会解释分布式的好处。
3. 高效率。Linux 内核也算是一个很大的软件了，如果版本控制系统运行起来慢吞吞的，确实是非常让人恼火的呢。
4. ……

Linus 当时(Linux 2.6.12 的那阵)说现有的版本控制系统都不行，他两个周就能写出一个更好的。结果他 4 月 7 日开始写 git ，在 4 月 20 日的时候内核已经开始使用 git 进行源代码管理了。参见这里的原文：

Linus began writing “git” on April 7′th [story], a rapidly evolving userland filesystem upon which various SCM implementations are being built or adapted. The 2.6 kernel source is already managed in a git repository, with the first succesful git release being 2.6.12-rc3 on April 20′th

当然可用离好用还是有很远的距离的，不过 Linus 确实很厉害了！后来 git 由其他人维护，并且在用户界面上进行了改进，现在已经相当好用了。另外一个有名的开源的分布式版本控制系统是 mercurial ，这个是由 Python 写成的，不知道在效率一条上满不满足 Linus 的要求，呵呵！其时各种分布式版本控制软件在开源社区是很流行的，有时候下载一些软件的时候就看到如果要获取最新代码，就要用作者使用的版本控制系统来进行抓取，像 Arch 、bazaar 、monotone 、darcs 一类的，都是使用得比较多的分布式版本控制系统。

为什么分布式版本控制系统会流行起来呢？ sishen 在他的 Blog DistributedSCM or not? 里面提到了传统的版本控制和分布式版本控制模型之间的差别。下面说一下我自己的看法：

• 更方便的 Merge 。分布式管理必然导致大量的 Branch 和 Merge 操作。因此分布式版本控制系统都特别注意这方面。在传统的 CVS 里面制作 Branch 和 Merge 简直就是噩梦，Subversion 作为一个用于替代 CVS 的系统，专门改进了 Branch 操作，在它的主页上可以看到这样一句话：
  

  Branching and tagging are cheap (constant time) operations

  There is no reason for these operations to be expensive, so they aren’t.

  Branches and tags are both implemented in terms of an underlying “copy” operation. A copy takes up a small, constant amount of space. Any copy is a tag; and if you start committing on a copy, then it’s a branch as well. (This does away with CVS’s “branch-point tagging”, by removing the distinction that made branch-point tags necessary in the first place.)

  然而似乎人们没有注意到，Branch 是轻松了，可是 Merge 呢？如果不能很方便地 Merge 回来，做 Branch 仍然是噩梦。事实上，我就经历过在开发团队里面由于队友操作不对而在 Merge 的时候把我的许多代码都覆盖掉了。当时正是使用的 subversion 。虽然源代码仍然在历史里面，但是要去一个一个地找出被覆盖掉的文件并恢复过来确实是一件很难忘的事情。

• 更轻松的管理。传统的版本控制系统使用中央仓库，一些仓库相关的管理就只能在仓库上进行。赋予开发团队每一个人中央仓库的管理权限是非常不好的。但是有时候确实会比较不方便的地方。
• 更健壮的系统。分布式系统一般情况下总是比单服务端的系统要健壮，因为但服务端一旦服务器挂掉了整个系统就不能运行了。然而分布式系统通常不会因为一两个节点而受到影响。
• 对网络的依赖性更低。虽然现在网络非常普及，但是并不是随时随地都有高速网络，甚至有时候根本没有网络可以访问。低速的网络会让人心情烦躁，有时候就呆呆地盯着屏幕上的 commit 进度，什么事情也干不了。而没有网络连接更是致命的：你无法 commit ！这表示你进行任何改动以前都必须小心翼翼，否则你可能再也找不会你曾经写的一些代码了。
• 更少的“仓库污染”。我不知道用“仓库污染”这个词是否恰当。有时候你要做一个模块，它不是太大，所以没有必要为它新建一个 branch ，但是它又不是那么小，不可能一次提交就做好。于是便会提交一些不完整的代码到仓库，有时候会导致整个程序无法运行，严重影响团队里其他人的开发。大多数人在这种情况下的解决办法都是写完之后再提交。但是作为习惯了版本控制的人来说，进行不计后果的大幅修改是经常的事情，到后来突然发现自己先前的代码没有提交，就后悔莫及了。如果是分布式系统的话就不会存在这样的问题，因为本地仓库的修改不会影响到别人的仓库。当你完成并测试以后，就可以在邮件列表里面说：我已经把这个模块做好了。然后感兴趣的人就可以从你这里 pull 你的成果了。

然而，不管怎么说，现在传统的版本控制系统仍然是主流。许多源码 Host 站点如 SourceForge 和 Google Code 等都是使用主流的 subversion 作为源代码版本控制的工具。

事实上，有时候我把 subversion 和 git 混合起来用。因为二者都有忽略某些文件的功能，只要在 subversion 的目录属性里面忽略掉 .git 一类的文件，再在 .gitignore 里面忽略 .svn 等文件，两者基本上也能很和谐地合作。通常在本地工作，使用 git 控制，并在适当的时候用 subversion 提交一次。

事实上它们配合得相当不错。即使是像 rm 一类的命令。比如，先用 svn rm foo<code> 把 <code>foo 删掉了。当前目录下已经不存在 foo 了，不过 git rm foo 仍然是能正常工作的。不过这和更改文件内容不一样了，不能自动跟踪，只能每次都在两个版本控制系统下都执行一遍。虽然可以用一些简单的脚本来减少这种重复劳动，但是有时候混用两个东西确实有种提心吊胆的感觉。