subversion 曾經是我們親密無間的戰友，但自 從一年前部分團隊成員去了美國，我們和subversion的關係就開始出現了裂痕，首先是將subversion伺服器架設在美國後，中國開發人員頻繁 進行的一些操作變得非常緩慢，本來通過追溯**歷史便可找出原因的問題，卻因為網速緩慢，導致開發者將大量的時間耗費在等待伺服器響應，而不是分析問題 上。其次，由於缺乏it基礎設施方面的投資以及完善的備份策略，數次因為網路原因或者伺服器宕機，導致團隊無法從中國訪問版本管理伺服器，正常的提交、更 新操作都無法進行，最嚴重的是版本管理伺服器曾經在發布之前出現故障，導致伺服器上的資料不得不回滾到九天以前，給發布帶來了很大的風險。
從現象上看，版本管理伺服器不在本地是遭遇速度瓶頸的主要原因，本質卻是由於版本管理工具不能很好的根據團隊的規模和結構伸縮。對我們而言，比較理 想的版本管理解決方案是在中美兩地架設伺服器，加快各個操作的執行速度，伺服器之間自動同步來平衡兩地對於速度和**整合的要求。然而採用 subversion 作為版本管理工具，決定了伺服器僅能架設在一地。svk 可 以解決部分問題，但它的缺陷太多，操作起來非常不便。我們所面臨的備份問題則是由於在subversion的設計中，所有的元資料僅僅儲存在伺服器上，一 旦伺服器出現意外，元資料所包含的寶貴資訊便無從恢復。之前的教訓讓我們認識到如果採用subversion作為版本管理工具，就不能僅僅樂觀的假設服務 器不會出錯，必須有詳盡可行的備份計畫，通過不斷備份來規避風險。
subversion的這些天生缺陷讓我們把目光投向了dvcs （分布式版本管理工具），在這個家族中，比較成熟的產品有git 、mercurial 和bzr ， 相比之下，由於mercurial對linux，mac和windows平台有良好的支援，支援通過web方式訪問**庫，並存在成熟的 intellij、eclipse外掛程式，最終成為了勝出者，時至今日，它已經在我們團隊服役超過1年了，從0.9.4到1.1.2，每一次版本的更新，都 讓我們愈加喜歡這個設計精巧產品。那麼較之subversion，mercurial究竟勝在**？
mercurial帶給團隊的第乙個體驗就是快，原因很簡單，由於dvcs的工作目錄與**倉庫（central repository）別無二致，同樣儲存了全部的元資料，那麼subversion需要通過網路完成的操作(諸如提交、追溯歷史、更新等), mercurial可以在離線條件下通過操作本地倉庫完成（圖-1）。
圖-1
通過減少與**倉庫的通訊, mercurial加快了操作速度，減小了網路環境對團隊的影響，非常符合我們的需求。這種速度和可靠性的提高，對於時刻與版本管理工具打交道的開發者是 一種非常愉悅的工作體驗。此外，包含了全部元資料的工作目錄可以在**倉庫出現問題時（圖2-b）成為備用倉庫（圖2-c），而整個過程只需執行一條命令 即可。
圖-2
這樣，在is部門修復**倉庫的過程中，開發團隊依然可以通過備用倉庫交換修訂，日常工作在沒有**倉庫的情況下依然可以正常開展，**倉庫恢復 後，再將宕機期間所有的修訂通過備用倉庫同步到**倉庫上（圖2-d），這套機制可以作為經費和硬體設施有限團隊的備份方案。即便**倉庫完全損毀，所造 成的損失也非常有限，避免了使用cvcs時將「所有雞蛋放在乙個籃子裡」的風險。
在日常的工作中，我們常常利用mercurial靈活的分支合併來共享修改，協同工作。幾個月前在印度發布產品時，我需要在新的工作站上安裝開發環 境，由於**庫龐大而且網速緩慢，轉殖**倉庫的操作需要花費數小時才能完成（圖3-a），mercurial的靈活性使我可以將工作站指向已經存有** 的膝上型電腦來執行轉殖操作（圖 3-b），在數分鐘後工作站就完成了全部的轉殖操作，之後再將它指向**倉庫（圖3-c），即可正常提交/更新**，大大節省了時間，提高了效率。
圖-3
在另乙個場景中，由於我所在團隊使用linux作為開發環境，在急於驗證某些功能是否在windows平台可以正常工作時，我們會將**在 linux工作站本地提交，再將windows工作站的工作目錄指向linux工作站，獲取更新（圖4-b）。之後，在windows 平台驗證功能，如果功能存在問題，可以修復後再將修訂從windows工作站提交到linux工作站（圖4-c），最終由linux工作站執行測試並將全 部更新同步到**倉庫（圖4-d）。mercurial的分布式特性讓開發團隊敏捷的分享修訂，更有效率的開發。
圖-4
本地倉庫的存在，使mercurial對小步前進更加友好 。小步前進意味著開發者在不破壞任何現有功能的前提下，每次修改少量**並提交。這兩個需求讓使用集中式版本管理工具的開發者常常處於兩難的境地，」不破 壞現有功能「與「每次修改少量**並提交」意味著存在便於分析的細粒度需求以及開發人員必須掌握增量式的物件建模、重構，資料庫設計、遷移等技術。難於小 步前進體現的是團隊成員經驗和技術的欠缺，然而解決這些問題不是一朝一夕之功，本地倉庫的存在給了開發者更大的自由，允許開發者頻繁提交而無需顧忌是否每 一次提交都不會破壞現有功能，在**經過若干次提交到達穩定狀態時再與**資料庫同步。通過使用mercurial，使得小步前進這個實踐得以在團隊開 展，在大家體會到實踐帶來的好處後，再追求高質量的小步前進。
mecurial靈活的分支合併策略使我們可以選擇與cvcs(集中式版本管理工具如subversion，cvs等)非常相似的架構（如圖-1所 示），這樣，團隊在更換版本管理工具後依然可以工作在相對熟悉的環境中。在(圖-1)所示的結構中，開發者需首先架設**倉庫，再從**倉庫轉殖出工作目 錄，在開發過程中，開發者將修訂提交到本地倉庫，最後，在功能完成後將本地倉庫的所有修改同步到**倉庫。除了最後一步，其餘步驟和cvcs完全一致，開 發者可以很快對mercurial總體架構建立初步的認識。mercurial的基本命令與cvs/subversion非常類似，熟悉cvs /subversion的團隊可以依然工作在熟悉的命令列環境。從結構到命令，mercurial做到了對cvcs使用者友好，降低了學習曲線，讓開發者可 以相對輕鬆的跨出從cvcs到dvcs的第一步。如果僅僅想作一下嘗試，又或者公司的政策不允許將版本管理工具從subversion遷移到 mercurial，mercurial還提供了hgsubversion 外掛程式可供選擇，它可以將mercurial作為subverion的客戶端使用，這樣，既可以保留subversion版本管理伺服器，又可以在本地採用mercurial來享受dvcs的種種好處，使開發者可以非常安全過渡到dvcs環境。
毫無疑問subversion是非常優秀的版本管理工具，但是它有自己的適用範圍，並不是銀彈。拋棄 subversion，也不因為我們是新技術的狂熱分子，而是它無法伸縮來適應團隊的結構變化。對於希望嘗試dvcs的團隊，我的幾個建議是：決策者首先 要識別團隊的痛點，對問題域有清醒的認識，而不能僅僅追趕技術潮流，其次是使用它、慢慢的接受它，如果團隊僅僅止於理論方面的學習，各種方案的論證，是無 法掌握dvcs並利用它來提高團隊效率的，最後整個團隊需要持續學習dvcs背後的設計思想，對於問題域的抽象以及豐富的外掛程式的使用方法。這些知識將直接 或間接的幫助團隊提高進行**版本管理的能力，更有效律的管理**。
感謝我的同事楊哈達 ，初悅欣 ，喬梁 和陳金洲在我寫作過程中提供的無私的建議和幫助。和楊哈達 的討論讓我對於dvcs的理論有了更清楚的認識，初悅欣和我一起重構了插圖，喬梁和陳金洲對於文章的結構提出了很多意見和建議。
這篇文章是我在工作中從熟悉的subversion遷移到mercurial的經驗分享，在這個過程中有不適應，也曾經犯了很多錯誤並獲得了許多經 驗。希望讀者能從這篇文章中有所收穫，從dvcs在我們團隊的實踐了解到dvcs可能帶給自己團隊的價值，更有信心的進入dvcs領域。
胡凱，thoughtworks敏捷諮詢師，近2年一直從事持續整合工具cruise 以及cruisecontrol 的設計開發工作。 對於web開發，敏捷實踐，開源與社群活動有濃厚的興趣，可以訪問他的個人部落格 進行更多的了解。
為什麼我們要放棄Subversion
subversion 曾經是我們親密無間的戰友，但自從一年前部分團隊成員去了美國，我們和subversion的關係就開始出現了裂痕，首先是將subversion伺服器架設在美國後，中國開發人員頻繁進行的一些操作變得非常緩慢，本來通過追溯 歷史便可找出原因的問題，卻因為網速緩慢，導致開發者將大量的時間...
為什麼要放棄Xmind選擇Effie？
資訊化時代下，要將零碎化的資訊整合成系統化的知識，少不了一款資訊管理工具。目前很多人使用的是xmind，通過xmind思維導圖軟體，將乙個個的知識點全部串聯在一起，或者是通過這款思維導圖軟體做詳細計畫表等等，儘管xmind是思維導圖軟體裡面的翹楚。但相對於xmind，我更喜歡這款剛發布不久的 黑馬 ...
我們為什麼要思考演算法
源頭 演算法 的中文最早出現在中國漢代的數學名著 周髀算經 中。周髀算經 卷上有 數之法出於圓方。圓出於方，方出於矩。矩出於九九八十一 意思是 算數的方法都出於對圓 對方的計算，其中圓出於方 圓形面積 外接正方形x圓周率 4 方出於矩 正方形源自兩邊相等的矩 矩的計算出於九九八十一 長乘寬面積的計算...