日常工作中，80%的SVN操作应遵从以下固定的步骤::

0. 工作之前，恰当的检出属于自己的代码(co)
1. 检入之前，必须重新同步本地代码(update)
2. 检入之前，后检入的人有责任解决合并冲突(ci)
3. 若无合适的理由(例:改善可靠性/可读性等)不得随意回退别人做过的修改

1. 恰当的检出属于自己的代码::

   • 意味着:
     1. 在一切开始之前请询问管理员，确定我们的SVN服务访问地址以及自己所属的工作区域 -- SVN项目目录

     2. 然后要开展协同开发，首先是建立本地副本，即，checkout——检出代码

        • 标准命令:

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

2. 修改文件之前要update。这意味着修改时的版本尽可能新，一旦发生冲突，解决它的工作量会比较小。

   • 标准命令:

     svn up

     • 在开发过程中应经常执行更新操作，以免与别人的工作发生冲突。

3. 修改完成并调试成功后，及时提交——commit

   • 标准命令:

     svn ci -m "注释文本"

   • 调试成功后——意味着:

     1. SVN仓库中应该永远只存可用的代码，未调试成功的实验性代码，不应该检入!

   • 及时——意味着:

     1. 本地代码与代码库中的代码差异越小，别人合并的难度也就越小(他们有比较大的概率能够拿到新的版本)
     2. 同一功能涉及的所有代码一次commit。不应该将涉及同一功能修改的代码分开commit，因为这会给日后的追踪带来麻烦。
     3. 将不同的功能单元修改分开commit。
        • 一方面，这样做能够尽早地commit，减少别人合并的难度；
        • 另一方面，由于cvs提供了回退到先前版本的能力，一旦由于某项功能修改造成问题，也很容易将那次修改的内容，而不是整个修改回退到正常的代码。

   • 提交时 写清 commit log(提交日志)

     • 写清 -- 记录为什么进行代码的修改，以及进行了什么样的修改，清楚的commit log能够帮助其他开发者在不仔细阅读代码的情况下了解修改的内容，从而极大地提高开发效率；另一方面，这些日志对于开发者自己，以及整个开发团队，都是非常宝贵的财富。

     • 具体的参考: 理性CommitLog约定