SVN下最高效打基线方法
- - CSDN博客推荐文章作者：张克强 作者微博： 张克强-敏捷307. 组织级scm建一个名为controlled的目录，当项目某文档通过评审后，组织级scm从项目目录下找到那文档，复制到controlled目录下. 请@scmeye软件配置管理社区 @E路向前--李忠利 @火星人陈勇 点评下这做法. 邱润HW：有什么东西是可以完全被控制的吗.
SVN下最高效打基线方法
标签：
svn
基线
方法
| 发表时间：2014-07-07 05:16 | 作者：zhangmike
出处：http://blog.csdn.net
作者：张克强 作者微博： 张克强-敏捷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基线方法！
作者：zhangmike 发表于2014/7/6 21:16:39 原文链接
阅读：0 评论：0 查看评论
相关 [svn 基线 方法] 推荐：
svn 钩子开启
- - 运维技术的个人空间背景: 公司的Svn很多人在用，有不少人在作修改后不添加注释，所以需要强制用户填写注释. 重命名svn主目录中hooks的pre-commit.tmpl文件为pre-commit，并添加可执行权限. echo "【注释】$content" 1>&2. echo "【注意】注释不能为空,请重新填写注释!!!" 1>&2.
SVN强制填写日志
- - CSDN博客系统运维推荐文章在F:\Repositories\版本库名\hooks下新建pre-commit.bat. rem 保证输入8个字符
%SVN_BINDIR%\svnlook log %REPOS% -t %TXN% | findstr "........" > nul
if %errorlevel% gtr 0 goto :err_action
rem 过滤空格字符
%SVN_BINDIR%\svnlook log %REPOS% -t %TXN% | findstr /ic:".
SVN之使用原则
- - 研发管理 - ITeye博客以下是我起草的部门SVN规范里原则的一部分. 必须提交注释，注明相关修改信息，例如bug号、任务描述等. 具体内容可采用约定或者设置的形式. 你所提交的改变将体现给其他开发者，要明白提交的后果，. 代码变动及时提交，避免丢失本地修改后无法恢复. 新增加的文件同时被提交，否则只在你本地能正常工作，导致其它人不能编译通过.
使用VisualSVN Server搭建SVN服务器
- - CSDN博客推荐文章使用 VisualSVN Server来实现主要的 SVN功能则要比使用原始的
SVN和 Apache相配合来实现源代码的 SVN管理简单的多，上手也没有那么复杂. VisualSVN Server的下载地址如下，是免费的，随意不必有顾虑. 1使用SVN，首先要安装 TortoiseSVN，就是上面的SVN下载地址.
SVN：合并一个分支到主干
- - P.Linux Laboratory本文内容遵从 CC版权协议, 可以随意转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明网址: http://www.penglixun.com/tech/program/svn_merge_branch_trunk.html. 原文在此，我只是翻译： http://www.sepcot.com/blog/2007/04/SVN-Merge-Branch-Trunk.
[原]强制 code review：reviewboard+svn 的方案
- - 赖勇浩的编程私伙局赖勇浩（ http://laiyonghao.com）. 我们团队在开发《天下盛境》项目的时候，制定和执行了比较好的 code review 策略，总结下来有几个优点：一是代码风格可控，代码质量有一定提升；二是新员工入职后能够得到更多人的指导，成长非常快；三是小 bug 频出的情况比我做《天》之前的项目少了至少一个数量组.
SVN提交更新的一个准则
- - BlogJava_首页查阅了一下网络和博客园，发现还没有一个明确地指导源码管理提交准则的相关文章，因此斗胆整理了一部分自己平时开发管理的心得，加上查阅了部分英文资料写了一个不算很完善的SVN提交准则. 负责而谨慎地提交自己的代码. SVN更新的原则是要随时更新，随时提交. 当完成了一个小功能，能够通过编译并且并且自己测试之后，谨慎地提交.
SVN:分支合并到主干
- - CSDN博客系统运维推荐文章1.先把主干代码下载到本地. 3.svn merge 分支目录 . 4.遇到冲突， 请见合并日志，选择"p"，记下出冲突的文件，人工编辑. 4.1 比如Index.action出冲突了，vi Index.action. 4.2 vi完成以后，删除冲突的文件 rm -f Index.action.*.
svn提交时强制注释
- -不少开发员提交修改的时候都不写注释，导致查看历史时很费劲，也不太符合规范. 有的公司要求每次提交修改时都写上bug号或者任务描述，那么如何在工具上防止开发员们不写注释呢. 利用svn的pre-commit钩子可简单实现此要求. 进入仓库project1/hooks目录，找到pre-commit.tmpl文件，重命名，去掉后缀.tmpl.