一直在用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/