SVN的操作说明以及备份策略

21 文件检出

安装TortoiseSVN后，SVN会跟Windows的资源管理器完美集成。点击右键，我们可以在菜单栏中选择“SVN检出”选项，输入要检出代码的文件库的URL地址，我们就可以检出该URL地址下的文件库的文件。默认情况下是检出最新版本的代码，如果需要，我们可以通过浏览日志，根据日志来找出想要的版本，然后在“版本”选项中指定相应版本就可以检出相关代码了 。

之后，对于同一个项目的主干开发，我们都在这个检出的代码文件目录下操作，而不是每一次提交或更新都重新检出一次。

22 文件添加

我们在本地创建的文件(包括目录)不会受SVN的控制，为了让其接受SVN的控制必须将其添加到文件库中。对于团队其他成员需要的文件，如代码文件、某些模块的a文件（由于某些需要，该模块代码不公开），我们必须让它们接受SVN的控制，并且保持最新的版本。

23 文件删除

当我们需要删除无用的文件(包括目录)时，不能使用Windows的资源管理工具，而必须使用SVN本身的删除文件功能。这样该文件被删除后，其所有修改历史仍然保存在SVN服务器中，以后仍然可以获得该文件的修改历史。

24 文件改名

当我们需要对文件(包括目录)进行改名的时，不能使用Windows的资源管理工具，而必须使用SVN本身的文件改名功能。这样该文件被改名后，其改名前的所有修改历史仍然保存在SVN服务器中，保持连续的修改信息。

25 文件更新

其他团队成员提交到SVN上的改动不会自动更新到你的本地拷贝中来，我们需要通过更新文件操作来获取其他成员对项目文件所做的修改。SVN更新文件操作会把文件库里的文件与本地文件进行合并，从而达到了同时保留其他成员的修改及本地的修改的目的。如果无法自动合并则会发生冲突，需要使用文件比较工具进行手工合并，合并完成后才能提交已解决冲突的文件。冲突的详细解决方法见第三章——冲突解决。

在团队开发时，更新是一件很重要的工作，可以保持团队成员之间的工作内容一致，因此要注意经常更新自己的工作拷贝，以保证自己能够获得最新的修改内容。

26 改动提交

我们对文件(包括目录)所做的一切改动，包括添加、删除、修改文件都必须提交到SVN服务器文件库中才能正式生效，之后团队的其他成员才可以获取你所作的修改。

提交是很重要的一项操作，要求做到：

 提交代码之前一定要保证修改后的代码能编译通过，不能提交编译不通过的代码。

 比较修改前及修改后的代码，把调试信息或其他不相关的信息去掉，再次确保提交的代码是正确的并且提交的是需要提交的文件。

 不要等到修改了很多代码才提交，而是相关小功能完成时就应该提交一次。这样以后发现问题时就很容易撤销有问题的代码——因为撤销只能针对一次提交，所以在一次提交里涉及过多的功能是不推荐的。

 提交时必须填写log信息，说明这次提交增加了什么功能或者修正了什么bug。这些信息有助于自己和其他团队成员了解整个项目的历史。当出现问题时也方便定位到对应的版本代码，所以log信息必须足够详细。

 事务性提交。也就是说提交要么成功，要么全部失败——即提交出现错误时会自动回滚，实际上没有提交任何东西。出现错误时，解决错误，再次提交上次提交的全部内容即可。

3 冲突解决

冲突的解决是我们使用SVN过程中的一个棘手问题，所以独立一节来谈论。

31 冲突的产生

冲突发生在多个成员同时对同一个文件进行修改的情形下。即当有其他成员已经提交了修改，而自己在本地拷贝中也对该文件进行了修改，而且修改的是同一个地方，那么在进行本地文件的更新时，SVN会不知道该选择那个修改（SVN上的修改还是本地的修改）来进行合并，所以冲突就产生了。

举例说，假如受SVN控制的文件Daytxt在SVN服务器上的当前内容如下：

图表 3 Daytxt文件在本地的修改

我们可以看到，在文本的第一行，SVN上及本地都做了修改。这样当在本地进行更新（提交之前必须先更新），SVN合并时就不知道monday后面到底该是work还是sleep，所以冲突就产生了。

而第三、五行是各自进行了修改，并没有冲突，所以这两行可以顺利合并，合并后可以看到所有人所做的修改。

32 冲突的解决

冲突发生后，SVN会在本地保存该文件的不同修改版本，见下图蓝色图标：

图表 4 Daytxt文件的不同版本

 Daytxtr35是版本35的Daytxt文件（本地拷贝最新版本）

 Daytxtr37是版本37的Daytxt文件（SVN上最新版本）

 Daytxtmine的是本地修改后的Daytxt文件

 Daytxt文件中包含了合并后的内容

321 简单冲突解决

对于简单的内容冲突，我们可以直接在合并后的文件上修改。在上例中，我们打开Daytxt文件，可以看到SVN合并后的内容：

图表 5 Daytxt合并后内容

我们看到没有冲突的修改：(play basketball)及（meeting）顺利地合并了，而冲突的部分出现了一些标记。其中标记

<<<<<<< mine

=======

之间包含的是本地修改的冲突部分的内容，即monday(work)。而标记

=======

>>>>>>> r37

之间包含的是版本37（SVN上最新版本）该部分内容，即monday(sleep)。

不失一般性，假如我们现在要保留的内容是monday(work)，那么我们只要把标记及monday(sleep)部分内容去掉即可：

图表 6 Daytxt解决冲突后内容

确保修改正确后，把Daytxt文件设置为“已解决的”。

图表 7 Daytxt标记为已解决

之后，后缀为mine,r35,r37文件全部消失，仅保留已解决冲突的Daytxt文件，提交到SVN即可。

322 复杂冲突解决

对于文件内容复杂的文件，上述的解决方法容易漏掉一些要修改的部分，解决起来也耗时耗力。这时要通过SVN提供的工具来解决。

选择SVN功能“编辑冲突”，打开冲突编辑工具:

图表 8 冲突编辑工具

上半部分的两个内容栏分别显示的是版本37的内容及本地修改的内容。

下半部分的内容栏显示的是合并后的内容。

每个内容栏左边的标记清楚地标识了该文件做了那些修改。

文件冲突的部分用红色显眼地表示了出来。在合并栏，点击冲突部分，点击右键，我们可以选择用哪个内容（SVN上最新内容或者本地修改内容）来解决冲突部分，也可以选择两个内容都使用，同时选择它们出现的先后顺序。

逐一解决各个冲突。确保所有冲突都解决后，保存文件，并标记为“已解决”的，退出该工具即完成冲突的解决。

4 加锁策略

事实上，解决冲突还有一种方法，那就是“严格加锁”。

“严格加锁”要求在编辑文件之前必须先对文件加锁，然后才能进行编辑。此时团队其他成员不能对该文件进行编辑，即保证了同一时刻只有一个人在编辑该文件，因此避免了冲突的出现。

那么，什么类型的文件我们应该采取“严格加锁”呢？

 Excel、等不可合并的文件，我们必须对其“严格加锁”。“严格加锁”的文件都标记为“可读”的，即不可编辑。要编辑这些“严格加锁”的文件，必须先对其加锁，加锁后文件更改为“可读可写”。编辑完这类文件后要第一时间提交。提交完成时，SVN会自动解开任何你拥有的锁 。

 文本文件，比如程序代码，SVN通常可以为我们合并改动，无须“严格加锁”。对于一些大家都频繁改动的重要源代码文件，可能会引起大量冲突，我们也不推荐“严格加锁”，因为加锁会导致大家持续得走来走去去询问加锁情况。正确做法是把文件分成数个逻辑单元，大家都修改各自的单元，减少合并时的冲突。

5 标签&分支

一个项目最初存放的目录我们称之为主干(trunk)。下面我们讨论除了主干之外其他存放项目的目录——标签(tag)和分支(branch)。

51 标签（tag）

版本号可以区分多次的代码修改，我们可以使用版本号来检出需要的代码，但对于重要版本的代码，如第三版发布代码，我们不希望记住r37这样的数字。这时，我们就可以通过创建标签来对SVN中这个发布版本的文件的这个时刻的状态创建一个“快照”，以后就可以通过这个标签名字来检出第三发布版本的代码。

标签其实是当前项目文件的简单拷贝，保存在标签所在的目录下。创建标签也是挺简单的，不过要注意：

 标签的名字一定要有描述性，可以仅凭名字就知道为什么要创建标签。

 不能过多地使用标签，只有在重要时刻或者发布版本时才可以创建标签。

 标签是项目文件在某个时刻的状态，不能对其进行修改 。

52 分支（branch）

分支跟标签一样，也是当前项目文件的简单拷贝，保存在分支所在的目录下。

分支跟标签的根本区别在于，标签不能对其进行修改，而分支就是为了某种目的的修改而建立的。在检出代码时检出指定分支即可，分支的操作跟主干上的操作完全相同。

521 何时创建

遇到下述情况，我们可以通过创建分支来解决问题：

 发布分支

当我们快要发布一个版本了，一个开发小团队要为这次发布做好准备，比如说修改一些收尾的bug。这时他们需要的是项目的稳定性，而同时我们还有其他团队要开发预计下次发布才会添加进去的功能，显然他们不能在同一份代码上工作，因此我们需要从主干中建立出一个发布分支，发布团队都从这个发布分支检出及提交代码。当程序被发布之后，这个分支依然是活动的。这样，如果客户报告了一些bug，团队会在这个发布分支中修正它们并视情况合并到主干中去。

 试验分支

当我们需要对项目做大范围的改动，并且这改动对系统的其余部分有深远的影响，而我们又不能保证这次改动一定能成功的时候就可以建立试验分支。如果试验失败了，可以废弃这个分支；成功了我们只要把分支的改动合并到主干代码中去就可以了。

其他情况，我们不建议创建分支，更不推荐在分支上创建分支，因为分支过多，合并时的冲突将会是一种难于解决的灾难。

522 合并分支

我们在分支上所修正的bug很可能在主干上或者其他分支上也存在，因为它们往往来自同一份代码，所以我们在分支上所做的改动有必要合并到主干或者其他分支中去。

对于简单的bug，一次提交就能解决问题的，那么我们只要记住提交新版本号，然后使用新版本号把改动合并到其他的受影响的主干及分支中去就可以了。

对于复杂的bug，可能需要多个开发者花几天的时间提交多次才能修好。这时光用版本号来记住修改的内容就有点勉为其难了。因此，我们可以使用标签来标记我们修正过程的开始和结束，然后使用这些标签帮助我们把修正的代码合并到主干和其他分支中去。整个过程如下：

① 给分支打个标签，标记bug修改开始。

② 测试重现bug，修正代码让新测试通过。

③ 提交你的改动到SVN上。

④ 重复步骤2、3，直到确定bug已经修正。

⑤ 再给分支打个标签，标记bug修正结束。

⑥ 使用两个标签来把修正的代码合并到所有其他受影响的主干和分支上。

6 注意事项

经常更新

 由于文件可能有多个人修改，应该经常更新你的工作拷贝中的文件，这样能降低发生冲突的可能性。

测试提交

 提交前先在本地进行测试。不允许将有错误的文件提交到SVN服务器上。

填写备注

 提交时一定要写备注：备注有助于其他人（包括三个月后的你自己）理解你对文件所做的修改。

整体提交

 提交文件时注意要提交一项改动所对应的所有文件，不要一次提交一个文件或者一次提交修改了很多功能的一堆文件。

发布标签

 对于每一个发布的版本都要建立标签：当用户告诉你发生某个问题时，你可以迅速地追踪到问题是在哪个版本引入的 。

附：测试自动化小组SVN使用指导原则

1 Project的构建

Project在SVN服务器上的目录架构如下：

SVN上的项目文件：

1 必须保证Trunk上的代码是最新的！定期对Trunk上的代码进行更新，各小组可根据各自实际情况自己把握

2 Tag是根据项目需要所打的标签，每一个发布的版本都要打Tag，主要是方便有需要时可以直接根据Tag返回到之前的状态，以便于分析、测试；Tag中必须包含相应的release文件及当时编译或发布时的源代码，必须有相关的文档注明项目背景、发布情况等。

3 Branch文件夹可以用作备份用，可以用个人名字命名文件夹；此外，Branch分支主要用来进行短暂或者探索性的开发使用，最终的软件版本必须更新、合并到Trunk主干上。

4 关于同一项目组开发环境的建议：同一项目组成员的开发环境最好一致，软件安装路径和Project文件存放路径最好一致。

2 版本号

关于版本号命名规则：主版本号子版本号修正版本号

1 项目初版本时，版本号为010；

2 当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1；

3 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位为 0；

4 当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1，子版本号和修正版本号复位为0；

5 编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，如果编译器不能自动生成，人手添加，数值代表为当前的系统时间。

例子：V101 Build090305 Rel111123

其它版本使用规则：

1 α（alphal）内部测试版

此版本表示该软件仅仅是一个初步完成品，只在组内内部交流，该版本软件的 bug 较多，限内部测试使用。

例子：V011 Build090305 alphal1

2 β（beta）外部测试版

该版本相对于α版已有了很大的改进，经过组内的测试，消除了严重的错误，但还是存在着一些缺陷，需要经过大规模测试来进一步消除。

例子：V012 Build090305 beta1

3 demo 演示版

仅限评审或讲解时做介绍使用。

例子：V013 Build090305 demo1

4 release 最终版

该版本意味“最终释放版”，在出了一系列的测试版之后，终归会有一个正式版本，一般情况下，release不会以单词形式出现在软件封面上，取而代之的是符号 (Rel) 。release版本发布时，必须将待发布的软件和相应版本更新记录打包在一起发出。

例子：V101 Build090305 Rel111123

3 权限限制

如果项目本身需要对项目组成员作不同的权限控制，可以考虑维护两个工程：一个工程里面有相应的源文件，一个则只有编译后的文件。

4 模块的版本维护

1 文件一般不需要版本，但要有详细的更新历史记录；

2 模块可以以版本来维护，具体可以不同的文件夹区分。

SVN项目，原本部署在10101348的电脑上，现在部门采购了一台更好的Server，IP为101013129。

所以，想把SVN项目从48上迁移到129上。做法：准备：

系统平台：windows server 2003

版本库：vos

源服务器：10101348

目标服务器：101013129

源SVN版本库的path: D:\svn\vos

要迁移到的path: E:\svn\vos步骤：

1．停止http服务，本文中用的是apache （源服务器）（目标服务器）

2．cd C:\Program Files\Subversion\bin(Subversion的安装目录)（源服务器）---------进入源服务器的svn安装目录

3．执行：svnadmin dump D:\svn\vos D:\svn\vos\vosdump（源服务器）

4将vosdump拷贝到目标服务器的任何地方，如E:\vosdump

5．cd C:\Program Files\Subversion\bin（目标服务器）---------进入目标服务器的svn安装目录

6．svnadmin create E:\svn\vos （目标服务器）----------------创建目标SVN服务器的vos项目

7．Svnadmin load E:\svn\vos < e:\vosdump （目标服务器。这个只是将源服务器上导出的版本库，导入到现在的服务器上。）

TortoiseSVN是一个SVN的客户端，下面是我以前不知道从哪复制的大致使用，希望对你有用：

五客户端的使用

1Checkout Repository

首先要Checkout服务器端的Repository，

所谓的Checkout就是指获得服务器端指定的Repository存储的所有文件。

这个Checkout和Visual Source Safe的Checkout意义完全不一样，

VSS的Checkout指的是锁定某个文件，如果你以前使用过VSS，

在学习Subversion时这个问题一定要注意。

Checkout的具体方式是：

在客户端新建一个空目录，比如：F:\Project1

在该目录上单击右键，在弹出式菜单中选中SVN Checkout，

之后在“URL of Repository”文本框中填入你想要连接的Repository的地址，

这个URL地址可以用浏览方式加入。

对于在本教程第二节建立的Repository，

URL应该是“svn://xxx/project1”

(xxx可以是服务器端主机名，也可以是服务器端的ip地址)。

然后点OK，会弹出一个认证对话框，

输入在教程第三节设置的用户名和密码。

点OK后就完成了对Repository的Checkout。

比如：在服务器端Repository中有一个atxt文件，

那么Checkout之后F:\Project1目录下也会出现一个atxt文件。

在本例中由于服务器端的Repository还未添加任何文件，

所以在客户端的F:\Project1下没有文件被Checkout。

执行Checkout除了会在F:\Project1产生Repository存储的文件及目录外，

还会产生了一个“svn”的隐含目录，该目录是由subversion管理的，

不要删除或者手工改动其中的文件和目录。

现在F:\Project1中的文件和目录就叫做Repository的“Working Copy”简写“WC”

(这个简写汗)。

以后对Repository中文件和目录的修改，添加，删除的操作，

都是通过对这个“Working Copy”的操作实现的。

Checkout执行完后，

会发现F:\Project1目录的图标的左下角附着了一个小的状态图标

(当F:\Project1目录中的文件改变时，这个状态图标也会随之变化)，

它表示F:\Project1是一个Repository的“Working Copy”，

F:\Project1内的所有文件和目录也会有类似的状态图标。

2添加文件

将要添加的文件或者目录拷贝到F:\Project1下，

然后在该文件或目录上单击右键，TortoiseSVN->Add，点OK。

如果添加了不止一个文件或目录，

则鼠标不要在F:\Project1中点中任何文件，

然后单击右键，TortoiseSVN->Add，

就可以添加多个文件或目录。

这时文件的状态图标会发生变化。

Add命令只是告诉本地的“Working Copy”将该文件纳入版本管理，

并没有将这个改变提交到服务器端，

如果想要别人也看见你对Repository的修改，你需要

在F:\Project1下单击右键，SVN Commit，

将你所做的修改提交到Repository。

文件的状态图标也会更新。

不管你在“Working Copy”内添加、修改、删除文件后，

要想其他人也看见你的修改，

都必须用Commit命令将所做修改递交到服务器端的Repository。

3修改文件

用文本编辑器或IDE对文件修改后，

文件的状态图标会变化，

然后单击右键，SVN Commit

提交修改，只有当执行Commit提交修改后，

你所作的修改才会反映到服务器端的Repository中。

4删除文件

删除文件时，选中要删除的文件或目录，

单击右键，TortoiseSVN->Delete，提交修改。

注意千万不要用“Delete”键来删除文件，否则将无法提交你的修改。

这一点对目录的删除来说尤为重要。

5放弃修改

当你添加、修改、删除文件后，决定放弃修改，

你可以单击右键，TortoiseSVN->Revert，

本地的“Working Copy”中的文件和目录会恢复到你修改前的状态。

6获取Repository的最新版本

当一个团队合作开发项目时，

每一个人都在不断的对Repository进行更新，

你需要不断的更新自己的“Working Copy”，

以获取项目最新的文件。

当第一次获得最新Repository的文件时，

我们用Checkout命令，前面已经介绍了，

以后再获取最新文件时就不用Checkout了。

而改用Update命令。

接着前面的例子，这时F:\Project1已经成为一个“Working Copy”了

(通过执行Checkout命令)，现在其他人已经对Repository进行了修改，

我想将别人的修改反映到我的“Working Copy”中，

具体的方法是：在F:\Project1目录上单击右键，

SVN Update。这时F:\Project1中的文件就是最新的版本了。

注意，如果当你的“Working Copy”中有被修改的文件，

或者有被删除的文件，并且还未提交这些修改时，

这些文件在执行Update过程中是不会被更新的。

比如你修改了F:\Project1下atxt文件，

还未提交修改，那么，

当你对F:\Project1进行Update时，

atxt文件是不会更新为Repository上的atxt文件的。

所以如果想放弃当前的所有修改，

并将F:\Project1下所有文件及目录更新到最新版本,

应该先对F:\Project1执行Revert命令再执行Update命令。

7subversion的版本控制模型

当你用subversion进行版本控制时，

Subversion会记录你对Repository进行的每一次修改(包括添加，修改，删除等等)，

每修改一次Repository都会产生一个新的Revision(修订版本号)，

不同的Revision代表了不同时刻Repository的状态，

因此我们可以用这个Revision回朔任意时刻Repository的状态，

就像时间机器一样，也就是说某一Revision

就是Repository在某一时刻的一个“快照”。

注意：Revision不是针对某一个文件或者目录，

而是针对整个Repository而言的。

每修改一次Repository，Revision 都会增加1。

Subversion的版本控制模型是一种叫做Copy-Modify-Merge

(拷贝-修改-合并)的模型。

考虑这种情况：

张三和李四是公司同一个部门的同事，

他们共同维护一个文本文件atxt，

并且对该文件进行版本控制，

因此他们把这个文件放到一个Repository上共同维护该文件。

周一上午9点，张三和李四同时想对atxt文件进行修改，

于是他们同时从Repository上取得该文件的最新版本(Revision 10)，

然后进行修改。过了三分钟，张三首先完成了修改，

他在该文件的第五行修改了一个单词的拼写(将Typo改为Type)，

于是张三对修改后的文件执行Commit命令，

将修改提交到服务器端的Repository中。

这时Repository的Revision变为11。

六分钟过后，李四也完成了他的修改，

他修改了该文件第十行上的一个单词拼写(将He改为She)，

于是他也对修改后的文件执行Commit命令，

这时Subversion 在提交修改时会发现，

李四修改的文件是Revision10的atxt文件，

而不是最新的Revision 11的atxt文件。

于是，Subversion 提示李四在提交修改前，

应该先将Working Copy更新到最新版本，

李四执行Update命令将Working Copy更新到Revision 11，

这时Subversion会提示已经完成合并，

李四的atxt文件的第五行的“Typo”已经变为了“Type”，

第十行还是“She”，就是说Subversion已经将张三的修改“合并”到李四的atxt文件中了。

之后，李四再执行Commit命令，就能将他对第十行的修改(将He改为She)

提交到服务器端的Repository中了(生成Revision 12)。

但是这种合并在某些情况下会变得复杂一些，

比如：李四对atxt文件的修改并不是第十行，

而是与张三同样修改第五行的单词，

李四将“Typo”改为“Typr”，并且提交修改，

这时Subversion会提示李四在提交修改前，

应该先将Working Copy更新到最新版本，

李四执行Update命令将Working Copy更新到Revision 11，

这时Subversion将Revision11的atxt文件与

李四修改的atxt文件进行合并时发现李四修改的同样是第五行，

于是Subversion就无法判断是李四的修改(“Tpyr”)

正确还是张三的修改(“Type”)正确，

因为他们都是在Revision10的atxt基础上作的修改。

这种情况叫做Conflict(冲突)，

atxt文件的图标会变成一个**三角。

这时，只能依靠李四自己去判断到底第三行应该修改为“Typr”还是“Type”。

当李四确定修改之后，在atxt文件上单击右键，TortoiseSVN->Resolved

告诉Subversion已经解决了Conflict。

这时再执行Commit命令就能提交修改(生成Revision 12)。

Subversion 这种控制方式保证了你对文件所作的修改都是基于文件的最新版本。

8“svn”目录

在客户端Working Copy的每一层目录中都会有一个“svn”目录，

该目录是Subversion进行管理用的目录。

不要手动修改其中的文件。

该目录存储了Working Copy的一个副本

(实际存储副本的地方是F:\project1\svn\text-base目录)，

比如：F:\Project1是一个Working Copy，

该目录下有两个文件atxt和btxt还有一个子目录ccc，

子目录ccc中还有一个dtxt文件。

“svn”目录中存储的是你最近一次执行完Update或者Commit命令之后当前目录中文件的副本，

比如：F:\project1\svn\text-base中存储的atxt和btxt

是最近一次执行完Update或者Commit命令之后F:\project1下的atxt和btxt的拷贝。

也就是说你所作的修改都是基于“svn”目录存储的那些文件。

这种机制可以让我们在不连接网络的情况下，

将Working Copy中的文件恢复到修改之前的状态。

Subversion的Revert命令就是利用了这种机制来实现的。

比如你修改了F:\project1\atxt文件，

这时你又改变了主意想放弃对该文件的修改，

你可以单击右键，TortoiseSVN->Revert，

修改过的F:\project1\atxt文件

就会被F:\project1\svn\text-base中atxt文件的副本所替代，

使得atxt恢复到修改前的状态。

Working Copy中每一个子目录下都会有一个“svn”目录，

并不是只有最上层目录才有“svn”目录。

所以，F:\project1\ccc下也有一个“svn”目录，

该目录存储的是F:\project1\ccc\dtxt的副本

(dtxt的副本位于F:\project1\ccc\svn\text-base)。

也就是说每个“svn”目录只存储同级目录中的“文件”副本，

而不存储“目录”副本。“svn”目录存有许多重要的内容，

所以前面说在删除文件或目录时，

必须用TortoiseSVN->Delete，

而不能用“Delete”键来删除文件或目录，尤其是对于目录的删除。

9混合版本

Subversion的Working Copy被设计成一种能够包含不同版本的文件共存的形式。

比如F:\Project1是一个Working Copy，

该目录下有两个文件atxt和btxt。

执行Update命令，将Working Copy更新到最新版本（Revision 24）。

这时，atxt和btxt的Revision都是24

(其实对于单个文件来说并不存在Revision，

Revision是对于整个Repository而言的，

这里所指的是Repository的Revision24所存储的atxt和btxt，

但为了方便而采用这种描述方式，请注意，下同）。

之后，你的同事修改了atxt，并且提交了修改，

这时Repository的Revision就变成25了。

注意，这时你没有再次执行Update，

因此你的Working Copy的Revision还是24。

这时你修改了btxt文件，并提交修改。

因为Revision25并没有对btxt文件进行修改，

因此你对btxt文件的修改是基于btxt文件最新的版本，

所以不会出现Conflict。

当你提交btxt的修改后，产生Revision26。

这时你会发现你的Working Copy中的atxt文件并不是Revision25中的atxt文件，

它还是Revision24的atxt文件，而你的btxt文件是Revision26的btxt文件。

也就是说当你Commit时，你的Working Copy中只有你提交的那些文件是最新版本，

而其他没有修改的文件并不会更新为最新版本。

这样就造成了你的Working Copy由不同的Revision文件所组成

(Revision24的atxt文件和Revision26的btxt文件)。

前面说过在提交修改前必须保证你是在文件的最新版本基础上修改，

如果在这种混合版本的情况下，

怎样才能知道当前Working Copy中的文件是否为最新版本？

在前面所说的“svn”目录中有一个文件名为“entries”的文件，

该文件记录了当前Working Copy中的每一个文件的Revision，

因此当你Commit时，Subversion会从该文件中取得你提交文件的Revision，

再与Repository的最新Revision一比较就可以知道你修改的文件是否基于该文件的最新版本。

10文件的锁定

前面说过Subversion的版本控制模型是一种叫做Copy-Modify-Merge

（拷贝-修改-合并）的模型。

该模型在对文本文件进行版本控制时工作的很好，

但是有些需要进行版本控制的文件并不是文本文件，

比如说图像文件，这种模型在这种情况下就不能正常工作了，

因为文本文件可以合并，而二进制文件则无法合并。

所以Subversion从12开始支持一种叫Lock-Modify-Unlock

（锁定-修改-解锁）的版本控制模型。

在Windows下最常用的版本控制软件Visual Source Safe(VSS)就是采用这种模型。

这种模型要求在对一个文件修改前首先要锁定这个文件，

然后才能修改，这时，别人将无法对该文件进行修改，

当修改完后再释放锁，使其他人可以对该文件进行锁定，然后修改。

锁定文件的方法是：TortoiseSVN->Get Lock再点OK按钮，

这时就完成了对文件的锁定。

这时，如果其他人想对文件进行锁定时，

Subversion会对他提示该文件已经被别人锁定。

当你修改完文件后，然后单击右键，SVN Commit，

将修改提交，默认情况下，提交的时候就会对该文件解锁，

如果你想仍然锁定该文件，请在commit时弹出的对话框中选中keep lock复选框。

11文件的附加属性

在Subversion中，每个文件可以拥有一种叫做附加属性的东西。

附加属性描述了该文件所拥有的一些特性。

Subversion已经预定义了一些附加属性

（这里只是指Subversion已经定义了一些附加属性的“名称”，

并不是指已经将这些属性附加在文件上了，

比如默认情况下文本文件一开始不含任何属性，

直到人为的对该文件添加附加属性），

并且你可以对文件添加自定义的属性。

Subversion对待附加属性就像对待文件内容一样，

当修改了一个文件的附加属性（添加，改变，删除附加属性），

即使没有对文件的内容进行修改，

同样可以Commit该文件，就像更改了文件内容那样，

Repository也会生成新的Revision，

所以从某种意义上来说，

Subversion不区别对待文件的附加属性的修改和文件的内容的修改，

文件的附加属性可以看成是一种特殊的文件内容。

Subversion预定义了若干个附加属性，

这里只讨论“svn:needs-lock”属性，

因为它与我们上面的文件锁定会产生的一个问题有关。

其他的属性可以参考Subversion自带的帮助文档。

考虑这种情况，

张三和李四同时想对一个文件ajpg作修改，

张三在修改时先将该文件锁定，然后进行修改，

同时李四也开始对该文件进行修改，

但李四忘记了对非文本文件进行修改时应该先锁定该文件。

张三首先对该文件修改完毕，于是张三向服务器提交了他的修改。

之后，李四也完成了修改，当他提交修改时，

Subversion提示李四的文件版本不是最新的，

在Commit之前应先更新ajpg到最新版本，

由于文件无法合并，

这就意味着张三和李四之间必定有一个人的修改会作废。

应用“svn:needs-lock”属性可以避免这个问题。

当一个文件拥有“svn:needs-lock”属性时，

该文件在没有锁定时，文件的图标是灰色的，

表示该文件是一个只读文件（该文件的Windows只读属性的复选框为选中），

这个灰色的图标就会提醒想对该文件进行修改的人，

在修改该文件之前应该首先锁定该文件。

锁定该文件之后，文件的只读属性就会去掉了，

一旦释放掉锁，文件的图标又会变成灰色，

文件也会变成只读的了。

李四在这种情况下就会避免在没有锁定文件时对文件进行修改。

对非文本文件添加“svn:needs-lock”

属性应该在将该文件第一次添加到Repository时就设置，

当然，一个文件可以在任意时刻添加附加属性，

这样做是为了减少李四所遇到的那个问题发生的几率。

具体的方法是：

首先将ajpg文件拷贝到Working Copy中，

然后在该文件上单击右键，

TortoiseSVN->Add，告诉Subversion要将该文件纳入版本控制，

接着在该文件上单击右键并选中属性，

在弹出的属性对话框中选中Subversion页。

在下拉框中选中“svn:needs-lock”，

并在下面的文本框中填入“”

（其实这里填什么都无所谓，只要文件有“svn:needs-lock”附加属性就行），

之后点Set按钮，“svn:needs-lock”附加属性就设置好了。

然后执行Commit命令提交修改。

这时当其他人执行Update时，

ajpg就会添加到他们的Working Copy中，

并且文件的附加属性也会随文件一起被得到。

可以看到ajpg此时的图标就是灰色的，

文件的Windows属性也是只读的。

12回到以前的版本

由于Subversion会记录你对Repository的每一次修改，

因此能够很容易的获得Repository以前某一时刻的状态。

比如：现在Repository的最新Revision是56，

这时我想看看Repository在Revision24时的状态，

可以在本地的Working Copy中单击右键，

TortoiseSVN->Update to Revision，

然后输入你想要回复到的Revision号，点OK按钮。

回到以前的版本还有一种情况是我想将Repository的

最新Revision的状态与以前某一个Revision的状态一模一样，

上面那种方法就不适合，

上面的那种方法只是将本地的Working Copy回复到以前的状态，

而服务器端的Repository并没有回到以前的状态。

将Repository的最新Revison的状态回复到以前某个Revision的状态具体的方法是：

先执行Update命令将Working Copy更新到最新的Revision，

然后在Working Copy中单击右键，

TortoiseSVN->Show Log，

弹出的Log Messages窗口中会显示该Repository的所有Revision，

选中最新的Revision，之后按住Shift键，

再单击你想回复到的Revision+1的那个Revision

（比如Repository的最新Revision是30，

你想将Repository的状态回复到Revision16，

那么就选中Revision30，再按住Shift键，

选中Revision17，

就是说选中Revision17到Revision30之间的所有Revision）。

然后在选中的Revision上单击右键，

选中“Revert changes from these revision”。

再点Yes按钮，就可以将Working Copy的状态回复到目标Revision。

注意，此时只是Working Copy回复到目标Revision，

之后应该用Commit提交修改，

这样Repository最新状态就与目标Revision的状态一样了。

这两种回复到以前版本的方式截然不同，

第一种方式是将整个Working Copy回复到某个Revision，

也就是说这种方式Working Copy中的“svn”目录所存的文件副本也与目标Revision的一模一样，

如果这时你没有修改文件，你将不能执行Commit命令。

而第二种方式客户端Working Copy中的

“svn”目录所存的副本始终是最新的Revision的文件副本

（这里我们基于一个假设：在Update之后没有其他人对Repository做修改）。

这种方式就像是我们自己手工将Working Copy的文件状态修改为目标Revision，

在修改之后提交修改一样。

13查看修改

有时我们对Working Copy的许多文件进行了修改，

这些文件位于不同的子目录，我们就可以在Working Copy的最上层目录单击右键，

TortoiseSVN->Check For Modifications，

弹出的对话框就会显示你所做的所有修改明细。

还有一种情况是我们的Working Copy已经很久没有执行Update命令，

我们想看看Working Copy中有哪些文件已经发生修改了，

这时就可以在Working Copy的最上层目录单击右键，

TortoiseSVN->Check For Modifications，

在弹出的对话框点击Check Repository按钮后，

就会显示服务器端已经修改了的文件。

该方法还有一个用途就是查看文件的锁定，

当你想锁定一个文件时，你想先看看这个文件有没有被别人锁定，

点击Check Repository按钮会显示服务器端Repository所有被锁定的文件，

如果你想锁定的文件不在这里面，那就说明该文件目前没有人锁定。

Subversion支持linux和windows，更多是安装在linux下。

svn服务器有2种运行方式：独立服务器和借助apache。2种方式各有利弊。

svn存储版本数据也有2种方式：BDB和FSFS。因为BDB方式在服务器中断时，有可能锁住数据，所以还是FSFS方式更安全一点。

一、下载相关软件

代码如下:

wget http://subversiontigrisorg/downloads/subversion-161targz

代码如下:

wget http://subversiontigrisorg/downloads/subversion-deps-161targz

二、安装及配置

1、解压：(要在同一个目录下)

代码如下:

tar -zxvf subversion-161targz

tar -zxvf subversion-deps-161targz

2、编译安装：

代码如下:

/configure --prefix=/usr/local/svn/

make make install

3、把SVN相关命令路径添加到环境变量

代码如下:

echo "export PATH=$PATH:/usr/local/svn/bin/" /etc/profile

source /etc/profile

三、建立测试仓库

1、建立SVN的根目录

代码如下:

mkdir -p /opt/svn/

2、建立一个测试仓库

代码如下:

mkdir -p /opt/svn/svntest/

svnadmin create /opt/svn/svntest/

3、修改配置文件

在cd /opt/svn/svntest/conf/目录下有三个文件：

svnserveconf 是svn的配置文件

authz 是设置用户权限的配置文件(可自定义文件名，在svnserveconf的authz-db = authz中指定)

passwd 是设置用户名和密码的配置文件(可自定义文件名，在svnserveconf的password-db = passwd中指定)

代码如下:

vi svnserveconf

修改如下：

代码如下:

[general]

anon-access = none

auth-access = write

password-db = passwd

authz-db = authz

==================================================================

代码如下:

vi authz

修改如下：

代码如下:

[svntest:/]

92cszcom = rw

#给svntest仓库添加一个名称为92cszcom的用户，权限为可写。

==================================================================

代码如下:

vi passwd

修改如下：

92cszcom = 123456

#由于是测试，密码设置为123456

四、在客户机安装svn客户端

1、下载地址：

http://codegooglecom/p/rails4scm/downloads/detailname=tortoisewin32svnmsi

2、下载完成后，直接next安装即可，安装完成后需要重启生效。

五、启动服务器及测试

1、启SVN服务，并指定SVN的根目录：

代码如下:

svnserve -d -r /opt/svn/

2、检查服务是否已经正常起来：

代码如下:

netstat -tunlp | grep svn

结果如下，则表示正常监听3690端口

代码如下:

tcp 000000:36900000: LISTEN 8646/svnserve

3、测试

在桌面上新建一个名称为svntest的目录，在此目录上点击右键，选择Checkout，在首行填写svn服务器的IP地址及仓库名称

  登录成功后如下图(文件夹上有个绿色的勾)

看情况；

1：如果是二进制文件（比如声音视频）这种只要是2个人都在本地修改了，别人抢在你前面提交，你再提交就过期了就显示**三角背景的感叹号。（本地会多生成2个带问号的版本识别文件，你们2个的起始版本、目前在服务器上的版本）

2：如果是文本文件（包括txt/c/java/js等等主流能被SVN自带的编辑工具识别的文件）就会出现2种情况

如果你们修改的不是同一行代码，那么你更新后本地还是红色，只是你本地的某些行数代码会和服务器同步（也就是别人的修改会自动合并到你本地）

如果你们修改的是同一行代码，那你更新后因为你们的对同一个文件同一个地方的写法不同就会导致服务器认为你们之间有理解上的冲突，就会用**感叹号标识这个文件。（本地会多生产3个带问号的识别文件，你们2个的起始版本、你修改的文件、他修改的文件，如果用TSVN的编辑冲突，会弹出一个文本框会把这3个版本都打开）

switch用于在同一个版本库内不同分支之间的切换

relocate用于版本库访问地址变更时，重新定位版本库

比如，由于SVN服务器更换到另一台主机上，这是SVN服务器的地址改变了，那么各客户端就无法连接SVN服务器了，这时各客户端就需要执行relocate，将本地工作区的连接到新的服务器上去

而如果同一个版本库内，如果有多个分支，比如你现在正在trunk上开发，但需要切换到某个分支上开发，那么你可以用switch来进行这个切换操作，这时SVN会比较trunk和这个分支之间的差异，将差异部分传送到你的本地工作区，而不用将整个分支传送给你，从而避免巨量数据的传输。switch操作之后，你所进行的update、commit操作都变成了针对那个分支，当你在分支上的工作完成后，还可以再次switch回trunk。

switch还有另外一些用途，比如希望让分支中的某个文件夹保持和trunk同步，因为有人正在trunk的这个文件夹中进行开发，在分支中想用到开发的最新成果，那么就可以在分支的这个文件夹上设置swtich到trunk，这时update整个分支的话，就会把trunk上的这个文件夹取下来了。但是，当然你如果修改了这个文件夹的内容，commit后也是提交到了主干而不是提交到了分支。