1. 每個人都只合並自己的修改
有時候一個fix會涉及多個人的修改。
2. 每一個fix就合並一次，以免修改太多，記不清
大部分時候一個fix都要反反復復修改，並且修復的同時，可能還會新的需求過來。
3. 合並後提交時，在注釋中寫明合並到了哪個版本。
雖然可以寫的清楚，但是在log中也不好查找，而有時候合並是要跳過某些版本的。
大家都在“抱怨”這個合並過程，並且前幾天還出現過一次嚴重的問題。當時，由於著急發布，而合並時又出現了，開發人員就用主分支中的最新內容覆蓋了發布分支中的代碼，一些還沒有測試的代碼就被發布了。還好那天沒有出現大的問題，隨後就有穩定版本上線。一個很現實的問題擺在了眼前：如何才能很好地跟蹤合並歷史？？
有高手推薦了Git，我本人並不對反對使用Git，但是現在改用Git，必然會帶來更多的學習開銷。不過好像也沒有別的方法，就開始嘗試git。在Git的介紹中，提到了一個顯著的特性就是合並跟蹤，而最意外的收獲就是：SVN從1.5（2008年呀！再次鄙視一下自己的孤陋寡聞）開始就支持合並跟蹤了。那就繼續使用SVN了。 先交代一下項目中使用SVN的場景：CentOS，Apache2 + Subversion
到服務器上看下當前SVN服務器的版本（svn --version）是1.4，首先想到的就是升級：
# yum update subversion
還是真有福氣呀，現在Cent OS中的倉庫中已經有了1.6.11。
然後在本地工作目錄使用TortoiseSVN更新，得到錯誤信息：could not open the requested svn filesystem。在服務器上查看httpd的error.log，發現了：(20014)Internal error: Expected FS format '2'; found format '4'。
原來服務器端程序升級完以後，倉庫也需要升級：
# svnadmin upgrade myrespository
倉庫升級完畢後，重新啟動httpd，再使用用TortoiseSVN更新時，又得到了另外的錯誤：Can't open file '/var/www/svn/myrepository/db/txn-current-lock': Permission denied。看起來是權限有問題，不過myrepository的權限都屬於apache.apache，好像是沒有問題。於是進入myrepository，查看個子目錄或者文件的權限，發現其中一個新文件format屬於root.root。和其他目錄下的format進行對比，果真是這個文件有問題，使用：
# chown apache.apache format
進行修改。然後再重啟httpd服務。
完成了以上步驟後，客戶端和服務器端都可以正常使用了。
這時，當完成一次合並後，再合並時就會發現已合並的版本變成了灰色。
