SVN之使用原则

标签: svn 原则 | 发表时间:2013-11-21 00:54 | 作者:leeleo
出处:http://www.iteye.com

以下是我起草的部门SVN规范里原则的一部分。

  1. 文件提交时要求 必须提交注释,注明相关修改信息,例如bug号、任务描述等。具体内容可采用约定或者设置的形式。
  2. 你所提交的改变将体现给其他开发者,要明白提交的后果, 提交之前要慎重
  3. 代码变动及时提交,避免丢失本地修改后无法恢复。
  4. 在提交之前要 编译代码并修正错误。要保证 新增加的文件同时被提交,否则只在你本地能正常工作,导致其它人不能编译通过。
  5. 提交之前要 测试所改变的应用,测试改变后的效果是否达到预期的目的。
  6. 多次检查提交的内容。提交之前应 先做SVN更新或与资源库同步,注意到SVN关于冲突、错误的信息。资源库同步会告诉你将要提交的内容与资源库内容之间的差别,确认它们是不是你真正想要提交的。
  7. 尊重其他开发者的代码,在重大变更之前与他们协商。 SVN并不能替代开发者之间的交流
  8. 提前宣布修改计划。当你计划进行修改,需要影响到SVN里的许多文件时,先通过邮件或者当面通知其他开发者。例如,修改底层数据库模块时,有可能影响到业务逻辑层调用数据库模块的地方。这样其他开发者会有准备,也会对修改提出意见和建议。
  9. 使用自动提交。SVN一次可以提交多个文件,所以,请一次提交所有相关的文件,即使它们不在目录下。这样可以确保代码在提交前后都是正确的。
  10. 不要将格式修正和代码修正混合提交。修正代码格式包括增加缩进、减少空格等,如果把它们同代码修正一起提交,很难从日志或资源库同步信息里发现代码的修正。所以应该把修正问题与修正格式分开提交。
  11. 每次提交尽量是一个最小粒度的修改。比如一个debug提交一次,一个小功能提交一次。
  12. 每日进行开发工作之前更新代码。避免与昨天其他开发者的代码冲突。
  13. 所有的代码文件编码格式应该是UTF-8的。包括的类型如java, jsp, xml, php, html等。
  14. 提交的文件必须是开发者共用的程序文件,私人测试程序、程序缓存、图片缓存文件不要提交到SVN里。作为一个特例,eclipse的工程配置文件.project可以提交到SVN。一些常见的文件和目录可以加到SVN属性的忽略列表里,包括Thumbs.db、/build/、*.class、/classes/、/data/等等。

转: http://www.kuqin.com/shuoit/20131104/336062.html



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [svn 原则] 推荐:

SVN之使用原则

- - 研发管理 - ITeye博客
以下是我起草的部门SVN规范里原则的一部分. 必须提交注释,注明相关修改信息,例如bug号、任务描述等. 具体内容可采用约定或者设置的形式. 你所提交的改变将体现给其他开发者,要明白提交的后果,. 代码变动及时提交,避免丢失本地修改后无法恢复. 新增加的文件同时被提交,否则只在你本地能正常工作,导致其它人不能编译通过.

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:".

使用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.

SVN下最高效打基线方法

- - CSDN博客推荐文章
作者:张克强    作者微博: 张克强-敏捷307. 组织级scm建一个名为controlled的目录,当项目某文档通过评审后,组织级scm从项目目录下找到那文档,复制到controlled目录下. 请@scmeye软件配置管理社区 @E路向前--李忠利 @火星人陈勇 点评下这做法. 邱润HW:有什么东西是可以完全被控制的吗.