1.库的存储结构
版本库文件结构如图所示：
Code文件夹为源码文件夹，doc为文档目录文件夹，
1.1 branch：分枝文件夹
当多个人合作，可能有这样的情况出现：John突然有个想法，跟原先的设计不太一致，可能是功能的添加或者日志格式的改进等等，总而言之，这个想法可能需要花一段时间来完成，而这个过程中，John的一些操作可能会影响Sally的工作，John从现有的状态单独出一个project的话，又不能及时得到Sally对已有代码做的修正，而且独立出来的话，John的尝试成功时，跟原来的合并也存在困难。这时最好的实践方法是使用branch。John建立一个自己的branch，然后在里面实验，必要的时候从trunk里取得更新，或者将自己的阶段成果汇集到trunk中。
1.2 tag: 标签
在经过了一段时间的开发后，项目到达了一个里程碑阶段，你可能想记录这一阶段的代码的状态，那么你就需要给代码打上标签。
1.3 trunk：主干
主干，一般来说就是开发的主要呆的地方，比较稳定的发布版本一般放这个地方。
文档等文件放入doc文件夹中。
branch文件夹开发人员可读可写，测试人员可读。新功能开发或者bug修复完毕，经过单元测试无误后，提交申请，由项目经理合并进主干线路。
tag文件夹，由项目经理在固定时间间隔备份
trunk文件夹，项目经理可读写，开发人员可读，测试人员可读。当开发人员通过分支或者打补丁的形式修复bug后，由项目经理合并进主干线路。
2.基本操作
2.1 搭建一个工作环境
新建一个空白文件夹
检出版本数据库数据。
选择svn检出
输入版本库主干目录的url地址，https://192.168.10.100/svn/project/code/trunk，导出版本库文件。
并设置检出目录地址。
D:softsample
点确定继续
点击“总是接受”。
输入用户名，密码。
版本库检出成功，如上图所示，绿色勾表示状态正常，其他图列示意请参考附录A：
强制写log
为保证版本库有良好的可读性，须设置在每次更新或者修改文件版本时，必须设置其属性为强制写log。
对工作副本点右键，选择属性。
选择subversion选项，设置其属性
选择new，新建属性
在property name 的下拉菜单中选择为tsvn:logminsize属性，并设置property value值为1，即log最小字节数应该为1.并勾选上apply property recursively 设置其属性为递归。
2.2 上传，更新版本库
对当前工作目录点右键，出现如下菜单。
Svn update 是把服务器上版本库更新到本地
Svn commit 是把本地文件更新到服务器。
2.3 版本日志
选择 TortoiseSVN-show log，可以查看历史的版本。对针对历史版本做比较和更改
对某一版本点右键可查看详细操作菜单
Compare with working copy
将你的工作版本与选中的版本进行比较。默认的比较工具是与 TortoiseSNV 一同发布的TortoiseMerge，如果日志对话框是针对文件夹的，那么就会出现一个被修改的文件的列表，你可以单独地查看每个文件所做的修改。
Show changes as unified diff
将选中的版本作为单一差异文件(GNU补丁格式)查看。相对于可视化的文件比较器，它更难阅读，但它将所有的变化显示在一个格式更为紧凑的文件中。
Compare with previous revision
比较选中的版本和以前版本。它与比较工作副本类似。对于文件夹，这个选项首先会显示已修改的文件对话框让你选择要比较的文件。
Compare and blame with previous revision
显示已修改的文件对话框，让你选择文件。追溯选中的版本和旧版本，用可视化差异工具比较结果(仅对于文件夹)。
Browse repository
打开版本库浏览器，基于选中的版本，在版本库中检查选中的文件或目录。
Create branch/tag from revision
从选中的版本建立一个分支/标记。这个选项很有用。比如: 如果你忘记建立标记，并且提交了某些你不想使其进入发行版的修改。
Update item to revision
将你的工作副本更新到选中的版本。如果你想要你的工作副本折返到过去的某个时间，或者在版本库中有一系列提交而你想每次只更新工作副本一小步，那这个功能就很好用。你最好是更新工作副本的整个目录而不是单一某个文件，因为如果只更新某个文件，否则你的工作副本就可能不一致。
如果你想要永久撤销先前的更改，使用 复原到此版本。
Update item to revision
恢复到某个以前的版本。如果你做了多处修改，然后决定要返回到版本 N，你就可以使用这个命令。恢复的修改位于你的工作副本，在你提交之前，并不会影响版本库。注意，这将会丢弃从那个版本以来的所有修改，使用选中的版本来替换文件/文件夹。
如果你的工作副本处于未修改的状态，在执行此操作后，工作副本将会显示为已修改。如果你已经进行了本地修改，这个命令将会把撤销的改变合并至你的工作副本中。
内部的动作是 Subversion 对选中版本之后的修改内容执行了反向合并，撤销这些先前提交产生的影响。
如果在执行这个动作后你察觉到你需要撤销这次撤销并且让工作副本返回到先前没有修改的状态，你应该在 Windows 资源管理器中使用 TortoiseSVN → SVN 还原，这个命令将会丢弃本次撤销动作带来的修改。
如果你只是想看看某个文件或者文件夹在先前的版本是什么样子，使用 更新至版本 或 保存版本为... 功能替代此操作。
Revert changes from this revision
还原选中版本所做的修改。还原的内容只在你的工作副本中，所以此操作完全不会影响版本库！要注意的是，这个操作仅仅还原该版本中的修改。不是将整个文件替换成选中的那个版本。它对于已经做过其它无关修改的还原早期修改非常有用。
内部的动作是 Subversion 对这个版本的修改内容执行了反向合并，撤销先前提交产生的影响。
你可以使用上文复原到此版本中描述的撤销这次撤销。
Revert changes from this revision...
合并选中的版本到不同的工作副本。可以通过文件夹选择对话框来确定合并到哪一个工作副本中，但是此操作没有冲突对话框，也没有尝试测试合并的机会。合并到未修改的工作副本是一个好主意，这样当合并不成功时你可以还原工作副本。当你想要将某个分支上选中的版本合并至其他分支时，这个功能很有用。
checkout...
检出你选择的目录的选中版本，创建一个全新副本。它弹出对话框，让你确认URL和版本，并且选择保存的位置。
Export...
导出选择的文件/目录的选中版本。它弹出对话框，让你确认URL和版本，选择导出位置。
Edit author / log message
编辑之前提交时的日志信息或是作者。
Show revision properties
查看和编辑任何版本属性，不仅仅是日志信息和作者。
Show revision properties
将选中版本的详细日志信息复制到剪贴板。它会复制版本号，作者，日期，日志信息，以及每个版本的改变项目列表。
Search log messages......
在日志信息中搜索你输入的的文字。这个操作搜索日志信息，也搜索由Subversion建立的提交行为总结(最底部的面板中的内容)。搜索大小写无关。
2.4版本库浏览器
浏览当前版本库内容。
2.5 检查修改
可检查当前目录做过修改的文件
2.6 版本分支图
版本分支图能够显示分支/标签从什么地方开始创建，以及什么时候删除。
2.7 锁定解锁文件
Get lock功能可给某一文件加锁，比如开发人员a从版本库里面下载aaa文件进行更改，但他不想别人在他之后修改此文件，于是他可以给此文件加锁，如开发人员b需要修改aaa文件，必须先由开发人员a对aaa文件进行解锁后，才能进行修改。
3. 创建以及应用补丁
对开源工程(比如本工程)来说，每个人对仓库都有读访问权，并且任何人都可以对该工程做出修改。那么如何控制这些修改呢？如果任何人都可以提交自己的修改，那么这个工程可能永远都会处于不稳定状态，而且很有可能永远的瘫痪下去。在这种情况下，修改需要以补丁文件的形式先递交到有写访问权限的开发组。开发组可以先对该补丁文件进行审查，然后决定将其提交到仓库里或者是退还给修改者。
创建一个补丁文件
修改欲修改的文件内容后，在当前目录选择TortoiseSVN → Create patch...
勾选修改的文件，确定，会生成一个*.patch的文件，可以通过邮件或者ftp方式将此文件发送给有权限写目录的开发人员。
应用一个补丁文件
开发人员收到*.patch 文件后，进入本地工作副本目录，点击TortoiseSVN → apply patch... 系统会弹出一个打开文件的对话框，让你选择要应用的补丁文件。选择接受到的patch文件，确定，系统会弹出一个小窗口列出所有被更改了的文件。依次双击每一个文件，检查所做的改变，然后保存合并后的文件。远程开发者的补丁现在已经应用到了你的工作副本上，你需要提交它以使每一个人都可以从代码库访问到这些修改。
4.分支以及合并
4.1 分支
a.新建一个空白文件夹。
b.点击鼠标右键checkout，把svn服务器上的库文件下载到本地，注意，不用下载全部的文件，只下载trunk下主干文件就够了
c.下载后对文件夹点右键，选择branch/tag选项。建立一个分支。
设置好分支文件夹的路径，创建一个属于自己的分支。每个分支存在寿命应该尽量的短，否则在跟主干合并时会造成很多冲突。
注意：勾选上switch working copy to new branch./tag，把分支设为当前工作目录。
这样当对程序有改动时，就直接commit到分支目录了。
4.2 合并
4.2.1 從開發主線合併至分支線路
由于要开发一个新功能，从主干新建一个分支后，主干又有其他的变化，需要保持分支的最新状态，所以需要从主干把新内容合并过去。操作步骤如下：
A：在分支目录下点击鼠标右键，选择merge选项。
B：在弹出框中选择“Merge a range of reversion”选项。
C：在URL TO MERGE FROM 选择主干文件的路径
https://192.168.10.100/svn/project/code/trunk
REVISION RANGE TO MERGE 这里可选择版本号，如不选择，则默认最新版本。
D：下一步可先点击test merge查看下测试合并结果。
如果修改与update得到的代码不冲突，则自动合并。如果冲突（比如对同一行代码进行了修改），则出现”One or more files are in a conflicted state.“红色警告，并产生几个文件记录冲突。如下图所示。
此时点击edit conflict按钮，解决冲突。
出现界面，分为”Theirs”、”Mine”和”Merged”3部分，表示”别人修改的内容”、 ”我修改的内容”和”合并后的结果”3部分。我们是要将”别人修改的内容”和”我修改的内容”有取舍地合并起来，形成”合并后的结果”。 合并一般分为4种情况： 保留”我的修改”,舍弃”别人的修改”。鼠标右键点击Mine框的相应行，点击”Use this text block”。 舍弃”我的修改”,保留”别人的修改”。鼠标右键点击Theirs框的相应行，点击”Use this text block”。
保存，退出
并点击resolved按钮，为文件解决冲突。
解决之后如图所示
即分支文件已更新。
4.2.2分支線路合併回 開發主線
最後我們的 tes1分支已經將新功能開發完成且測試無誤，所以要將 分支線路 ( /code/branches/tes1 ) 的最終版本合併回 開發主線 ( /code/trunk )，這時的步骤如下：
A：切换到trunk主干目录文件夹下面。
B：选择合并
C：选择Reintergrate a branch 选项。
D：设置url为欲合并的分支目录
E：合并成功，若出现冲突请按照 4.2.1 D步骤解决。
F：手工检查更新过的单元文件，核对无误后上传到版本库。
4.2.3 分支线路合并回主线（通用模式）
这是复兴合并的通用情况。你要 Subversion 做如下事情: “计算[从]主干的最新版本[到]分支的最新版本所需要的修改，并将这些修改应用到(主干的)工作副本。”最终结果就是主干看起来与分支一模一样。
选择merge two different trees选项
From下面这里填写主干的url地址。
To下面填写欲合并的分支文件地址
合并成功，请检查无误后提交版本库
附录A.图标状态示例
一个新检出的工作副本使用绿色的对勾做重载。表示 Subversion 状态正常.
在你开始编辑一个文件后，状态就变成了已修改，而图标重载变成了红色感叹号。通过这种方式，你可以很容易地看出哪些文件从你上次更新工作副本后被修改过，需要被提交。
如果在更新的过程中出现了冲突，图标会变成黄色感叹号。
如果你给一个文件设置了svn:needs-lock属性，Subversion 会让此文件只读，直到你获得文件锁。具有这个重载图标的文件来表示你必须在编辑之前先得到锁。
如果你拥有了一个文件的锁，并且 Subversion 状态是正常，这个重载图标就提醒你如果不使用该文件的话应该释放锁，允许别人提交对该文件的修改。
这个图标表示当前文件夹下的某些文件或文件夹已经被调度从版本控制中删除，或是该文件夹下某个受版本控制的文件丢失了。
加号告诉你有一个文件或目录已经被调度加入版本控制。
横条告诉你有一个文件或目录被版本控制系统所忽略。这个图标重载是可选的。
这个图标说明文件和目录未被版本控制，但是也没有被忽略。这个图标重载是可选的。
附录B、常见问题
1.出现树冲突的几种情况以及解决方案。
当一名开发人员移动、重命名、删除一个文件或文件夹，而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。
1. 开发人员 A 修改 Foo.c 并将其提交至版本库中
2. 开发人员 B 同时在他的工作副本中将文件 Foo.c 改名为 Bar.c，或者仅仅是删除了Foo.c 或它的父文件夹。
更新开发人员 B 的工作副本会导致树冲突:
· 在工作副本中，Foo.c 被删除了，但是被标记为树冲突。
· 如果冲突是由于更改文件名引起的而不是删除文件引起的，那么 Bar.c 被标记为添加，但是其中却不包括开发人员 A 修改的内容。
开发人员 B 现在必须做出选择是否保留开发人员 A 的更改。在更改文件名的案例中，他可以将Foo.c 的更改合并到改名后的文件 Bar.c 中去。对于删除文件或文件夹的案例中，他可以选择保留包含开发人员 A 更改内容的项目并放弃删除操作。或什么也不做而直接将冲突标记为已解决，那样他实际上丢弃了开发人员 A 的更改。
如果 TortoiseSVN 能够找到被改名为 Bar.c 的原始文件，冲突编辑对话框将可以合并更改。这取决于在什么地方调用更新操作，它也许不能找到原始文件。
1. 开发人员 A 将文件 Foo.c 改名为 Bar.c 并将其提交至版本库中。
2. 开发人员 B 在他的工作副本中修改文件 Foo.c。
或者在一个文件夹改名的案例中...
1. 开发人员 A 将父文件夹 FooFolder 改名为 BarFolder 并将其提交至版本库中。
2. 开发人员 B 在他的工作副本中修改文件 Foo.c。
更新开发人员 B 的工作副本会导致树冲突。对于一个简单的文件冲突:
· Bar.c 被当作一个正常文件添加到工作副本中。
· Foo.c 被标记为添加(包括其历史记录)并且产生树冲突。
对于一个文件夹冲突:
· BarFolder 被当作一个正常文件夹添加到工作副本中。
· FooFolder 被标记为添加(包括其历史记录)并且产生树冲突。
Foo.c 被标记为已修改。
开发人员 B 现在需要做出决定是否接受开发人员 A 作出的结构改变并且合并她的更改到新结构下适当的文件中，或者直接放弃开发人员 A 的更改并保留本地文件。
要合并她的本机更改到新布局中，开发人员 B 必须先找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以使用日志对话 删除按钮进行清理并将冲突标记为已解决。
如果开发人员 B 认为 A 的更改是错误的，那么在冲突编辑对话框中她必须选择保留按钮。这样就会标记冲突的文件/文件夹为已解决，但是需要手工删除开发人员 A 的更改。又是通过日志对话框帮助追踪哪些文件移动了。
1. 开发人员 A 将文件 Foo.c 改名为 Bar.c 并将其提交至版本库中。
2. 开发人员 B 将文件 Foo.c 改名为 Bix.c
更新开发人员 B 的工作副本会导致树冲突:
· Bix.c 被标记为添加(包括其历史记录)。
· Bar.c 被添加到工作副本中，其状态为‘正常’。
· Foo.c 被标记为删除并且产生一个树冲突。
要解决这个冲突，开发人员 B 必须找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以使用日志对话框来完成这个任务。
然后，开发人员 B 需要决定 Foo.c 的新文件名中的哪一个需要保留 - 开发人员 A 改的那个还是他自己改的那个。
在开发人员 B 手工解决冲突后，使用冲突编辑对话框中的按钮将树冲突标记为已解决。
1. 开发人员 A 在主干上工作，修改 Foo.c 并将其提交至版本库中
2. 开发人员 B 在分支上工作，将 Foo.c 改名为 Bar.c 并将其提交至版本库中
合并开发人员 A 的主干更改到开发人员 B 的分支工作副本会导致树冲突:
· Bar.c 已经存在于工作副本中，其状态为‘正常’。
· Foo.c 被标记为缺少并产生树冲突。
要解决这个冲突，开发人员 B 要在冲突编辑对话框中标记文件为已解决，这样就会将其从冲突列表中删除。她接下来需要决定是否将缺少的文件 Foo.c 从版本库中复制到工作副本中，是否将开发人员 A 的对 Foo.c 的更改和合并到改名后的 Bar.c 或者是否通过标记冲突为已解决来忽略更改什么事也不做。
注意，如果你将缺少的文件从版本库中复制到工作副本中然后再标记为已解决，你复制下来的文件将被再次删除。你必须先解决冲突。
1. 开发人员 A 在主干上工作，将 Foo.c 改名为 Bar.c 并将其提交至版本库中
2. 开发人员 B 在分支上工作，修改 Foo.c 并将其提交至版本库中
当文件夹改名时有类似的案例，但是在 Subversion 1.6 中还未被识别...
1. 开发人员 A 在主干上工作，将父文件夹 FooFolder 改名为 BarFolder 并将其提交至版本库中。
2. 开发人员 B 在分支上工作，在她的工作副本中修改 Foo.c 。
合并开发人员 A 的主干更改到开发人员 B 的分支工作副本会导致树冲突:
· Bar.c 被标记为添加。
· Foo.c 被标记为修改并产生树冲突。
开发人员 B 现在需要做出决定是否接受开发人员 A 作出的结构改变并且合并她的更改到新结构下适当的文件中，或者直接放弃开发人员 A 的更改并保留本地文件。
要合并她的本机更改到新布局中，开发人员 B 必须先找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以通过适用于合并源码的日志对话框来完成这个任务。冲突编辑器仅显示工作副本的日志因为它不知道将哪个路径的更改合并进来，所以你需要自己找到它。更改必须要手工合并，因为没有办法自动的或者简单的完成此操作。一旦更改移植完毕，冲突的路径就是多余的并且可以删除。在此案例中，使用冲突编辑对话框中的删除按钮进行清理并将冲突标记为已解决。
如果开发人员 B 认为 A 的更改是错误的，那么在冲突编辑对话框中她必须选择保留按钮。这样就会标记冲突的文件/文件夹为已解决，但是需要手工删除开发人员 A 的更改。又是通过日志对话框帮助追踪哪些文件移动了。
1. 开发人员 A 在主干上工作，将 Foo.c 改名为 Bar.c 并将其提交至版本库中
2. 开发人员 B 工作在分之上，将 Foo.c 改名为 Bix.c 并将其提交至版本库中
合并开发人员 A 的主干更改到开发人员 B 的分支工作副本会导致树冲突:
· Bix.c 被标记为正常(未修改)状态。
· Bar.c 被标记为添加(包括其历史记录)。
· Foo.c 被标记为缺少并且产生树冲突。
要解决这个冲突，开发人员 B 必须先找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以通过适用于合并源码的日志对话框来完成这个任务。冲突编辑器仅显示工作副本的日志因为它不知道将哪个路径的更改合并进来，所以你需要自己找到它。
然后，开发人员 B 需要决定 Foo.c 的新文件名中的哪一个需要保留 - 开发人员 A 改的那个还是他自己改的那个。
在开发人员 B 手工解决冲突后，使用冲突编辑对话框中的按钮将树冲突标记为已解决。