SVN使用规范

为公司创建的SVN使用规范：

1. 上传时间：如当天工作超过2小时，请上传SVN.
2. 上传注释：必须添加简要注释，并遵循下面的规范。
3. 上传内容：可以Revision的代码，编译必须的library。 尽量排除：个头大的不能revision的文件。 不要上传：在编译的时候再次生成的东西！包括可执行文件。同时遵循下面的规范。
4. 规范中的所有命令，都能再乌龟客户端GUI里面实现。

* ALWAYS compile and test before checking in source code. Subversion revisions should correspond to revisions which compile.
    * Don't copy, rename and move directories and files with system shell commands. Use Subversion commands to "rm", "mv", and "add" directories and files and then commit changes when done. Work within Subversion.
    * Commit changes as a single logical changeset for one purpose. Thus all code changes for a single bug fix or enhancement should be checked-in together. This allows one to better follow the history log of changes.
          o Check-in code at the directory level and all changed files, recursively in the directory and subdirectories will be checked in together.
            svn ci -m "Check-in comment goes here" ./
          o Check-in files together by specifying them explicitly:
            svn ci -m "Check-in comment goes here" file.cpp file2.cpp ...
    * Tie Bug tracking and Subversion CM together:
          o Use comments when checking-in files into Subversion. Add bug tracking numbers to the comments so Subversion will reference Trac bugs.
          o If using Trac, add trac comments so that links are generated to the Subversion repository by placing the Subversion revision number in square braces (i.e. [1140]) in a Trac comment. In this way, Trac will have a direct URL link to Subversion.
    * If using Trac integrated with Subversion, refer to the Trac ticket in the Subversion check-in comment using a "#" in front of the Trac ticket number (eg. #65) This generates a hyperlink when the Subversion logs are viewed in Trac.
    * 补充一点！ 从Trac中也能直接引用Subversion. 用“r” in front of SVN revision. 比如新建了一个Ticket，叫“请大家测试GUI的修改版本”，然后内容中，包含“请查看修改版本r27”，就会自动在Trac中引用代码，做 diff了。
    * The "tags" branches are NOT to be used as working branches but are snapshots of an existing branch. The "tags" are for historical reference such as a release, well tested version or progress milestone.
    * Documentation and related artifacts should not be under the source tree but parallel to it. This isolates the source tree so that email notification triggers sent to developers upon source changes will only go out on source changes or regression build and test systems like Cabie will only rebuild and test on source changes rather than on unrelated documentation changes.