##

'''日常工作中，80%的SVN操作应遵从以下固定的步骤::'''
||<^><<Include(SvnRationalLoop)>>|| {{attachment:commitloop.gif}}||
 1. '''恰当'''的检出'''属于自己的'''代码::
  * 意味着:
   1. 在一切开始之前请询问管理员，确定我们的SVN服务访问地址以及自己所属的工作区域 -- SVN项目目录
   1. 然后要开展协同开发，首先是建立本地副本，即，'''checkout'''——检出代码
    * 标准命令:{{{

svn co svn://cvs.woodpecker.org.cn/woodpecker/zqlib/trunk
^   ^   ^            ^               ^        ^     ^
|   |   |            |               |        |     +- 主线目录
|   |   |            |               |        +- 项目目录
|   |   |            |               +- 仓库名
|   |   |            +- SVN服务域名
|   |   +- 访问协议,SVN支持从HTTP到file 等多种访问模式!
|   +- checkout 检出代码
+-- svn 命令和cvs类似是我们日常工作的基础工具命令

}}}

 1. 修改文件之前要'''update'''。这意味着修改时的版本尽可能新，一旦发生冲突，解决它的工作量会比较小。
  * 标准命令:  {{{
svn up
}}}
   * '''在开发过程中应经常执行更新操作，以免与别人的工作发生冲突。'''

 1. 修改完成并'''调试成功后'''，'''及时'''提交——'''commit'''
  * 标准命令:{{{
svn ci -m "注释文本"
}}}
  * '''调试成功后'''——意味着:
   1. SVN仓库中应该永远只存可用的代码，未调试成功的实验性代码，不应该检入!
  * '''及时'''——意味着:
   1. 本地代码与代码库中的代码差异越小，别人合并的难度也就越小(他们有比较大的概率能够拿到新的版本)
   1. 同一功能涉及的所有代码一次commit。不应该将涉及同一功能修改的代码分开commit，因为这会给日后的追踪带来麻烦。
   1. 将不同的功能单元修改分开commit。
    * 一方面，这样做能够尽早地commit，减少别人合并的难度；
    * 另一方面，由于cvs提供了回退到先前版本的能力，一旦由于某项功能修改造成问题，也很容易将那次修改的内容，而不是整个修改回退到正常的代码。
  * 提交时 '''写清 commit log'''(提交日志)
   * '''写清''' -- 记录为什么进行代码的修改，以及进行了什么样的修改，清楚的commit log能够帮助其他开发者在不仔细阅读代码的情况下了解修改的内容，从而极大地提高开发效率；另一方面，这些日志对于开发者自己，以及整个开发团队，都是非常宝贵的财富。
   * 具体的参考: '''[[RationalCiLog|理性CommitLog约定]]'''