svn/cvs除了copy效率比copy快，還有其他的優點：備份及復原…

之前 debian 的版本控制伺服器發生過怪客入侵事件，而他們的解決之道是立即讓伺服器下線，並比對所有協助開發的程式設計師手邊的沙箱，藉此找出有問題的程式碼。因為每個人手頭都有一份全專案副本，所以有跡可尋。

如果是發生在 copy 來 copy 去的專案中，那要比對程式版本的差異就麻煩了，因為可能沒有工程師有所有的專案程式碼。這最常發生在使用「copy」概念的軟體專案中，他們使用元件化、模組化的概念來開發程式，Amon負責A元件、Bill負責B元件，這樣雖不會有衝突，但如果Amon掛了，搞不好還得找個人來重寫A元件。

所以如果你用了 svn/cvs ，你還有機會快速比對被怪的程式碼以及每個程設師會幫你備份1個專案。

使用svn/cvs的重要觀念：人的溝通才能花解程式碼的衝突

幾天前跟一個在軟體業界滿長時間的朋友談程式碼管理的技巧，他說：「小專案一定不用版本控制，而大專案也不一定要用。」

這原因出在他們有一個慘痛的教訓。因為一個程設師忽視其他程設師的錯誤修正，強制把他的patch檔送 VSS 儲存庫(我不是故意指名道姓的，因為事實上，他們是用 VSS)，於是1個bug，兩個人解決，也就是等於沒人解決。所以他們衍生出使用版本控制器一定要用 lock 動作，單一檔同時間只允許1個程設師修改，而且不可以破壞別人建立的 lock 。這麼作，只是把 VSS 當作高級 cpoy 指令來用而已。

我跟這位朋友提到使用 svn/cvs 的一個重要觀念：每次 commit 前，要先作 update ，且要看看別人所修改的程式碼及註解，如果與自己的程式發生嚴重的邏輯衝突時，不是硬幹別人的程式，而是打個電話跟他聊聊。

如果軟體公司沒有正確地使用版本控制，而是使用老舊的copy思維。為此，他們會衍生出一種與 copy 相輔相成的工作模式：專業分工。把一個軟體專案元件化、模組化，切完再丟給工程師作，每個人專注自己的小區塊，出了問題自己解決，然後再找一位菜鳥程設師來作 SA ，時間到了，就跟大家要要程式碼，兜在一起跑。這麼作看似解決了程式碼衝突的問題，但也帶來新的問題：

1. 程設師漠視團體的效益，專注自己的效益。
   
2. 認為只要開幾次會，定下模組溝通的介面，就可以不再溝通了。
3. 少了彼此學習的機會。

可是如果你是正確使用版本控制器的，舉個例子( http://chinesetrad.joelonsoftware.com/Articles/TheJoelTest.html )來說說：「約耳老兄在Excel 團隊時有個規定，每天要將專案編譯1次，且導致編譯失敗的人必須從此負責重新編譯的動作(作為處罰)， 一直到有其他人出錯為止。這是個讓人不要導致編譯失敗的好誘因，同時是個讓大家輪流處理重新編譯的好方法，這樣大家都會知道怎麼做。」

當你可以綜觀整個專案時，你可以了解模組之間的關係，可以看看別人的程式精華，可以少1個SA(或許軟體公司對這個比較心動)，而你只是花1~3個小時，去學1個你未來都用得到的版本控制器，很划算吧!

等等，我聽到有人反應「如果公司不想讓所有人接觸整個專案呢」!這個例子我有遇到過，曾經就遇到一間公司要求1個工程師把商業邏輯都寫在資料庫的預存程序中，而另1個工程師則是撰寫網頁程式來呼叫這些預存程序，這公司希望產品不要讓1個工程師全把握住。遇到這種例子，就善用 subversion 的權限管理，把一個專案中的兩個模組設定1個只有A工程師可讀寫，另1個只有B工程師可讀寫。但我想，這個管 subversion 的人，該是公司老闆來，還是他美貌的秘書呢!