1. 基本的工作周期:
A 更新你的工作拷贝
$ svn update
B 作出修改
$ svn add/delete/copy/move
C 检验修改
$ svn status/diff/revert
D 合并别人的修改倒工作副本
$ svn merge/resolved
E 提交你的修改
$ svn commit
2. 在提交前需要做的动作:
$ svn status:
检查当前工作副本是否过期，另外可用svn diff查看细节。
$ svn update:
把其他人对代码做的修改，合并到你本机的副本。
3. 如果使用 svn rm 删除了不该删除的文件，如何进行恢复？
A 提交之前: $ svn revert PATH
B 提交之后: $ svn copy -r PREV SRC DST
4. 添加了不该添加的文件， 如何删除这些文件？
A 提交之前: $ svn revert PATH
B 提交之后: $ svn remove URL
5. 如果已经提交代码了，如何回滚到以前的版本
A. 上一版本：
$ svn cat -r PREV filename > filename
注意这个时候文件的状态是M，也就是说你可以提交你的修改。
B. 较老版本：
$ svn update -r NUMBER
但是不能将这些工作路径内的修改提交到代码库中。
6. svn 不会将当前目录下的链接加入版本控制，这意味着:
A.如果您不想把某些目录/文件加入版本控制，那最简单的办法就是：
在其他地方建立目录，然把在你的svn工作目录下用软链接链到那个目录
但此时要是svn status，链接文件会有?提示。
B.如果发现 check out 出来的文件缺少东西,
那很可能是因为在import的时候,链接类的文件/目录没有提交。
7. 处理冲突
在使用 svn update 的时候，若出现如以C 开头的提示信息，
说明你在本地的修改和版本库中的版本修改的地方重叠了，
也就是说，你修改了某一行，你的同事也修改了同一行。
这个就需要你自己手工去解决了。
当冲突发生时，要注意到有三件事情可以帮助你解决问题：
A. Subversion会给这个文件作出C标记。
B. 如果Subversion认为这个文件时可以合并的，它会一个冲突标记（特殊的横线来分开冲突的代码块）。
C. 对每一个冲突的文件，Subversion放置三个额外的未版本化文件到你的工作拷贝。
filename.mine
你更新前的文件，没有冲突标志，只是你最新更改的内容。
（如果这个文件不可以合并，.mine文件不会创建，因为它和工作文件相同。）
filename.rOLDREV
这个是你做更新操作以前的BASE版本，就是你在上次更新之后未作更改的版本。
filename.rNEWREV
这是Subversion从服务器刚刚收到的版本。这个版本就是版本库的HEAD版本。
要解决这个冲突，可以选择：
a. 手工合并冲突文件（检查和修改文件中的冲突标志）。
b. 用一个临时文件（三个中的一个）覆盖你的工作文件。
c. 运行svn revert <filename>来放弃所有的修改。
一旦解决了你的冲突，需要通过命令svn resolved让subversion知道并删除三个临时文件，这时才可以提交。
关于手工合并冲突，看看如下文本：
Mayonnaise
Lettuce
Tomato
Provolone
<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======
Sauerkraut
Grilled Chicken
>>>>>>> .r2
Creole Mustard
一连串的大于、小于、等于号是冲突标记，这些数据得全部删除才可以提交。其中,
<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======
是你在冲突区里面做的修改。
Sauerkraut
Grilled Chicken
>>>>>>> .r2
是别人在冲突区做的修改。
在冲突区中，或许你需要和你的同事沟通来安排冲突区的文本内容，
如果是程序代码，你需要和同事商量一下，中间的这段代码到底应该是什么样子的。
所有冲突区得到合理的解决之后，你就可以提交你的文件了。