筆者：張克強 在微博上：張克強-敏捷307
2014/7/6
方法一來自於我的一條微博：
組織級scm建一個名為controlled的文件夾，當項目某文檔通過評審后，組織級scm從項目文件夾下找到那文檔，拷貝到controlled文件夾下。
請@scmeye軟件配置管理社區 @E路向前--李忠利 @火星人陳勇 點評下這做法
針對方法一的點評例如以下
邱潤HW：有什么東西是能夠全然被控制的嗎？假如沒有，那就沒意義。假如有，用文件夾這樣做控制，應該不僅僅僅僅是命個名字吧。 (3月27日 08:54)
火星人陳勇：有沒有試驗過用SVN？感覺SVN直接打一個版本號號也不錯吧，呵呵。反正我如今全部文檔都在一個在線的SVN里邊管理着。怕出現版本號覆蓋問題。 (3月27日 17:56)
scmroad配置管理之路：svn 中有個東西叫tag (3月27日 18:03)
王海鵬Seal：七種浪費之：搬運不創造價值。
（3月27日 18:33）
繆劉俊：復制來了工作量[哈哈](3月27日 18:37)
stephen_wang_7971：補充：這里還包括Inventory的工作。
相同不創造價值(3月27日 19:09)
方法二來自於@火星人陳勇 的點評：SVN版本號號，由於SVN版本號號是SVN自己主動打上的，所以我理解直接打一個版本號號的意思就是記錄下這個號，抑或是在commit的comments里說明下，回頭直接查SVN的log就可以。
方法三來自於@scmroad配置管理之路：tag，SVN的tag相當於拷貝到可讀不可寫的文件夾下，文件夾名稱就是tag名稱。與Clearcase的Label是不一樣的。
以上討論。大家可能看不明確。以下小結下
方法一：源自於配置管理常說的三庫-開發庫、受控庫、產品庫。這是古老配置管理工具遺留下來的做法，看似穩妥，實質效率底下，轉移根本沒有增值，反而帶來一致性維護問題。
方法二：利用SVN自身的revision number。
最高效的方法是在關鍵commit時說明打基線，或者說明關鍵要點，比方評審后改動再復核通過，比方評審通過。
方法二更加正式的做法是利用專門的表格記錄關鍵點的Revision Number
方法三：利用Tag/Branch。拉出Tag和Branch后。對於基線（Tag)，要保持僅僅讀，看似方便，事實上有隱患。由於還有形態全然一樣的分支（Branch）
本文所稱SVN下最高效打基線方法是指上述方法二。
還在使用三庫的朋友們。是時候改進了。這應當有2%的全局效率提升！
不服的朋友。歡迎辯論！拿出更好的，更有效的SVN基線法！
版權聲明：本文博客原創文章，博客，未經同意，不得轉載。