SVN最有效的方法打基线

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

版权声明：本文博客原创文章，博客，未经同意，不得转载。