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.

html 裡面的 http/https 的路徑寫法

看到 這一篇文章 HTTP/HTTPS 的相對路徑, 又增長了一點學問. 一般我們在寫網頁的時候, 如果要附圖, 或附檔. 都是用相對路徑, 也就是 類似 /img/test.jpg 的方式. 文章裡面提到, 如果你的站台有http and https 兩種都提供的話, 用相對路徑的寫法可以解決.如果用絕對路徑的話, 就會在 user side 彈出一些警告的標注. 文章裡面提到 , 可以用 //www.2twn.com/img/test.jpg 的方式來解決相對應的問題.

不過在自己開發網站的過程中, 針對這樣的問題還是有在開發過程中, 還沒有找到一個比較好的解法. 已經有一個公開的正式網站, 一個內部測試網站, 一個開發者自己的網站. 有很多的圖片是不斷地會在公開網站加入, 測試網站跟開發網站怎樣可以獲取到相關的圖片???
目前, 是不管這一個問題. 但是, 測試網站上就沒有相對應的圖片, 測試人員會說有問題. 但是要把所以在正式網站的圖片移植過來也是很麻煩??? 天兵的是, 內部一些開發人員, 居然把會成長的圖片, 直接commit 到 svn 上面. 導致其他人在下載code 都會抓到一堆東西.