svn 使用法則 : 何時去開啟 branches

之前使用svn 都是沒有使用 branches . 正確講法是不太瞭解怎樣去使用. 直到最近遇到一些問題, 在想說因該要怎樣去解決. 首先, 在同一個目錄裡面, 放置了很多的control. 但是, 有些新的control 並還沒有完成, 如果針對目錄 update, 就會抓到不需要的檔案或目錄. 但是, 在測試環境要抓到其他新的. 之前就是手動來針對一些檔案作revision, 這兩天就來研究一下看有沒有指令可以update 部份檔案. 很不幸的, 從網路上找來的資料都顯示 svn 不能部份update. 那是不是svn 不是一個好的 version control system, 但是沒有道理svn 這樣多人用沒有這樣的功能.
找到其中一篇 Subversion Best Practices, 看完了以後才知道, 是自己的問題不是軟體的問題. 總歸一句話就是 紀律是建立在規範上面.
再過去, 所有的人都把自己寫的code 全部update to trunk 下面, 只把svn 當作一個檔案分類的辜能, 但是已經有很多 open source 的前輩, 開發過很多軟體也用svn 去作 version control system. 為何就沒有出現這樣的問題. 原來就是 紀律與規範的表現. 在 Subversion Best Practices 最後一段講到 Know when to create branches, 裡頭講到 三個運用branches 的模式.

The Never-Branch system
從來不用 branch的開發模式, 這就是我們現在所進行的方式. 但是這種模式是有前提的, 那就是每天commit to trunk 的code, 必須是經過測試跟認可, 沒有經過測試完成的不能commit to svn.

The Always-Branch system
每一個開發者針對每一各段落的開發, 要自己branch 那一段的code. branch code 被測試驗證完成以後, 才能merge 到 trunk. 這一個開發模式有一個比較大的缺點, 當多個開發者的branch在開發中, 需要互相引用的時候, 需要很多的手動工作, 才能完成.

The Branch-When-Needed system
這一個模式是 subversion project team 採用的方式. 這一個模式有下面的運作條件.

• 參與者每天要完成的code commit to trunk.
• 規則一 : trunk 的code 每一天要能被測試驗證完成, 不要引起其他人的困擾.
  
• 規則二 : 每一次commit 的變動量不要大到需要去 peer-review.
• 規則三 : 如果規則一二有衝突, 就是需要 branch 的時候, 表示該項變動, 需要多個需要多個changeset, 但是又不想要影響 trunk 的 穩定.
  

這樣的作法, 參與者要確實完成一個階段的測試後, 才能 作一次的commit to trunk.