作者：张克强 作者微博：张克强-敏捷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基线方法！
