作用：
防止代码丢失（本地删除了找不到）
行为受到控制（不能动别人代码）。
不同人之间代码的相互调用，且不会产生冲突
安装
服务器端：
服务器端配置时是有提供一个URL的。这个URL是客户端链接服务器时用的：
项目Test的仓库的地址
然后服务器端要配置用户和密码，用户才能在客户端使用：
客户端
安装后右键会出现：
SVN Checkout 是第一次链接服务器时用的，点击后：
如要链接项目Test，在服务器端点击Test，出现的是项目Test的URL地址。
把这个地址填写在Checkout 里。注意客户端和服务器不是同一台机器时，地址里的计算机名DADI-PC（服务器的计算机名）要换成服务器的ip地址。
443是端口号，是服务器端安装时设置的。
本地磁盘的存放路径：
设置完之后点击OK，第一次链接会出现下面的界面：
点击上面这个下次就不会出现了
然后输入用户名，密码：
注意选中下面 的 Save.... 下次不用再次输入。
本地磁盘里就多出了项目文件夹。里面有一个文件夹.svn。有这个文件夹，Test项目文件夹才能跟服务器端进行svn操作（增删改查等）
基本操作
提交操作
新增文件（是自己拷贝到或者在这个Test创建的文件），然后提交：
新建的文件，还没有提交，会有一个问号：
如Test 文件夹下有一个Test.java文件，在Test文件夹下右键---点击SVN Commit：
上面是写注释的地方，每次提交都写注释，写明自己为什么修改代码，防止有争论时忘记自己当时为什么修改，修改了哪里。
选中要提交的文件，但是点击 OK。就提交了。
所有的操作都是点击 OK 后 就完成了。（删除也是，更新也是，所以要注意，别不小心就删除了，或者更新把本地覆盖了。虽然SVN也可以再找回来，但是毕竟麻烦）
Status是状态：
non-versioned 无版本 说明是第一次新建项目，还没提交到服务器。
missing 是要删除时的状态
modified 修改后待提交
提交后的文件，有一个对勾：
删除操作
本地删除文件后，服务器端还是有的，操作同上。需要在Test文件夹下右键---点击SVN Commit：
missing说明是要删除的文件，选中---OK。服务器端也就删除了。
修改文件
修改后待提交的文件，是一个感叹号：
这一块区域显示的是，上次提交后，又有了变化的文件（修改了，新建的，删除的等等），需要再次提交的文件
常见问题
多个用户操作同一个文件
（1）B修改了A的代码
如A提交一个文件，然后被B修改了。等A要用时，一个update更新，发现代码不是自己原来提交的了，自己写的部分被修改了。
只有当前代码是最新版本，才能进行提交操作（要不你代码已经是很久以前的了，想提交进去直接覆盖最新的版本，你都不是在最新版本上修改的，谁知道你的代码有没有问题）。所以每天早晨第一件事就是更新代码。晚上最后一步是提交代码。
当A早晨更新代码时，发现自己的代码被修改了：
（这个Updated就是代码有修改的意思吗？）
如何找回代码，如何知道是谁修改了代码？
右击文件----TortoiseSVN ---Show log:
可以看到代码提交记录：
加号的是新建的意思，感叹号就是修改了的意思。可以看到谁在什么时间进行了什么操作。（如果提交时有些注释，Message里会显示）
然后点击要恢复的版本---选择恢复到此版本：
点击 Revert：
本地代码恢复（仍需要提交）：
（2）B删除了A的代码
第二天A一个更新，结果自己本地的代码也被删除了。
如何找回？
不能在文件上右击文件----TortoiseSVN ---Show log查看此文件的操作日志，就在这个目录下（是Test这个目录，这是前面下载代码时设置的本地仓库那个目录）右键----TortoiseSVN ---Show log，查看有多少人对这个项目提交了代码：
选择想要的代码，然后右键---保存（图里没有显示出来save，在下面）：
只要代码被提交过，以后所有的操作都会被SVN记录下来，本地丢失了没关系，但是如果服务器端的那个仓库丢失了，就真的丢失了，所有管理员要对那个仓库备份。
多人操作同一个代码，提交由先后，导致版本问题
（提交代码必须保证自己修改的最新版本，所以每天早晨最开始就是先更新代码）
AB都update了保证自己是最新版本，然后修改了提交，但是有先有后，B 先提交了，那Ａ提交时就会遇到版本问题，因为Ｂ提交后版本更新了一次，Ａ那边就不是最新版本了：
提交失败，提示是过时版本，需要更新版本。点击ＯＫ：
选择 更新。
这时候出现一个问题，你代码没有提交，但是最新版本的代码却被拷贝了下来（Ｂ提交的那个版本），并且和你的代码合并了（Ｍｅｒｇｅｄ）：
如果ＡＢ修改的不是同行的代码，那两人的代码合并就没有关系，你修改了第九行，我修改了第十行。合并后是正确的。依次点击ＯＫ提交上去就可以了。
如果ＡＢ修改的是同一行代码，ＳＶＮ就合并不了，那就会出错。
更新之后，提交之前本地就多了几个文件：
黄色感叹号说明合并失败。此时不要再提交了。
打开黄色感叹号的文件：
上面是你想提交的代码，下面是现在已有的代码（两个代码修改的是同一行），此时就需要ＡＢ协商了。
．ｍａｉｎ文件里是你自己想提交的代码。
．ｒ１０ 是老版本，是你修改之前的版本。其实是ＡＢ都没有修改时的那个版本
．ｒ１１ 是你提交时服务器端的最新版本（数字越大，版本越新）。其实就是Ｂ提交的最新版本。
通过自己修改的版本，原来的版本，Ｂ修改的版本，双方可以协商出应该如何修改，是保留Ａ的修改还是保留Ｂ的修改。
不要直接在黄色感叹号Test.java里修改，容易删除不干净。
如果保留A的修改， .main文件覆盖黄色感叹号文件Test.java（把.main文件修改文件名为Test.java即可覆盖）。
如果保留B的修改，直接右键操作文件恢复（直接修改文件名覆盖）：
得到的就是最新版本了（B提交的版本）而且那三个文件也消失了：
如果都不要，用原来的版本， 就用 .r10文件直接修改文件名覆盖。
冲突的地方很多的情况：
AB都添加了代码，又都修改了同样位置的代码，然后提交有先后，B先提交，A提交出错，提示先更新。
这时候就不要去更新了。把自己的代码先复制到其他地方。
然后通过图中的操作把自己的代码恢复，得到上一个自己取得那个版本：
然后再更新，得到目前最新版本（也就是Ｂ提交的版本）。为什么不直接更新取Ｂ提交的最新版？因为更新的话还会多出来另外三个文件，比较麻烦？
然后把自己复制出去的修改一个名字拷贝进来。ＳＶＮ有磁盘对比代码的工具。选中两个文件，右键，如图操作：
得到对比结果：
第一个方法都没有修改，第二个方法ＡＢ都修改了，需要双方协商。第三个是双方都新加的方法，都保留就可以了。
协商修改完，再次提交就可以了（自己复制进来的那个删除就可以了）。因为Ａ这边提交了，此时Ｂ那边需要更新一下
Ｂ修改了Ａ的方法，Ａ没有发现，继续写代码
如图，Ａ的方法里的操作被Ｂ修改了。
当双方都没有发现问题，经过很多版本提交后，比如测试时，发现那个方法报错了，但是已经很多版本过去了，不知道是谁因为什么修改的代码，怎么办？
ＳＶＮ还有一个历史记录比对的工具
打开Ｓｈｏｗ ｌｏｇ：
得到历史版本记录：
此时选中最新的版本１８和版本１７，选择对比版本：
发现此方法已经被修改了，再依次选择版本１７和１６，再次对比，直到找到这个方法被修改的时候：
可以看到是版本１６时，Ｂ修改的代码。然后就可以找Ｂ询问为什么修改了。