一直在用subversion做版本控制，一直用得很happy。后来听说了Git，一个分布式版本控制系统，但是一直没有细细研究，因为我认为subversion够用了。今天看了看ubuntu的开发页面，它们在用一个叫Bazaar的分布式版本控制系统，于是出于对ubuntu的信任，爱屋及乌，想看看ubuntu选择的版本控制系统有何独到之处，看介绍的时候其实并没有看进去，但实然间想通了为什么要用分布式版本控制系统，并且要在自已的日常开发中使用它。
首先来看看用subversion过程中遇到的一些闹心的事情：
一，我做为管理员（项目由我创建，我要负责提交的代码的检阅确保代码随时能够编译并进行新版本发布）时遇到的问题：
*某个组员对subversion的使用一知并解，比较粗心，他会：提交一些不必要的文件内容（编辑器产生的临时文件、备份文件，对发布时所需的程序配置文件的一些本地修改，甚至用于成员间的临时文件传送），他会不写提交时的注释或很随便。做为一个开发组你无法阻止他们提交，即使技术上可行你也不可以或者说是无权这么做，相对于我这个管理员所需付出的额外维护精力，对开发组成员和积极性的伤害才是致命的。结果显而异见，做为管理员的我基本上每天都要修复提交的代码中的问题，并通知各个成员立即更新工作拷贝，并对犯事者进行又一次教育，svn不是这么用的。终于有一天svn仓库所占用的空间占光了分区空间，于是重建仓库，项目的历史没有了，程序开发中记录的一些真知灼见和经验教训也找不到了，程序旧版本的bug也因为检不出当时的源代码而未了未之。
二，我做为组员时遇到的问题：
版本控制就像是一付后悔药，一个月光宝盒，可以撤消/重做是多么惬意啊，还记得洗完澡后将干净衣服扔进桶里时的抓狂吗，反正这种情形下我是到处在找CTRL+Z键。毫无顾虑地使用版本控制让开发的日子更轻松，也更自信，可以大胆地尝试各种思路，不用担心自已偶然间天才的代码或者是想法在某个烦燥的中午被删掉。但是subversion也不是能够想用就用的，为什么呢：
通常来说，提交的东西一定是好的、完整的，它不会让整个项目处于一种不可用的状态（听说在某些公司，如果你捅了这个篓子，晚上你就得搬个席子半夜在机房里守着项目自动编译过程，直到遇到下一个像你一样的倒霉蛋），问题是在你搞定这个好的、完整的提交部分的过程中，你得不到subversion的庇佑，你的月光宝盒被紫霞给抢走了，你得小心地按delete键，你不敢删除代码中不洁的代码，如果你像我一样用惯了svn的话，在这段时间里你一定没有安全感。我真的需要自已的私有的版本控制，怎么办？svn给的标准答案是：１，创建分枝，可以解决问题，问题是必须提交代码到中心服务器，会占用服务器的资源（主要是硬盘空间），网络不可达时就不管用了，这很常见，如：公司比较小，svn仓库搞不好就在头儿的笔记本上，万一头儿不在就用不了了；你在家里做开发也可能暂时用不了；另外，你的私有版本可能有点不能见光，比如：你仅仅是想尝试一下新技术，你想搞个个人版，你不服气原有的设计想弄出个加强版过几天放出后一鸣惊人。２，在本地上建个仓库，导入原项目的内容，不过问题就更严重了，和原项目同步不容易。
而分布式版本控制系统则从根本上解决了上述问题，估且认为它和分枝是在本地上的Subversion吧，你可以方便地从源分枝创建自已的分枝，它有单独的历史，不依赖于某个中心服务器，在必要时你可以从某个外部分枝上更新内容，提交自已对源分枝的修改，发布自已的分枝以便别人在此基础上创建新的分枝。是的，这个时候为了让读者能够打心眼里认同我对分布式版本控制系统的推崇，我得恶补一下分布式版本控制系统的知识，至少得装出有过那么几年分布式版本控制系统的使用经验，最后来句“其实我也是经过了数十年的努力才取得了今天的成就”做为文章的结尾，闲话说多了，总结一下：Subversion解决了CVS的一些问题，DCVS解决了Subversion的一些问题，这只是版本控制的又一次发展，况且只要你愿意，DCVS也可以传统的集中式服务器模式运行，有理由相信DCVS会是对Subversion的一次完胜。
最后，做为一名写下本文章的DCVS菜鸟，当然免不了要推荐一些阅读资料：
分布式版本控制系统入门：http://www.ibm.com/developerworks/cn/aix/library/au-dist_ver_control/