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

2.1 文件检出

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

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

2.2 文件添加

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

2.3 文件删除

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

2.4 文件改名

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

2.5 文件更新

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

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

2.6 改动提交

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

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

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

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

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

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

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

3. 冲突解决

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

3.1 冲突的产生

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

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

图表 3 Day.txt文件在本地的修改

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

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

3.2 冲突的解决

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

图表 4 Day.txt文件的不同版本

 Day.txt.r35是版本35的Day.txt文件（本地拷贝最新版本）

 Day.txt.r37是版本37的Day.txt文件（SVN上最新版本）

 Day.txt.mine的是本地修改后的Day.txt文件

 Day.txt文件中包含了合并后的内容

3.2.1 简单冲突解决

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

图表 5 Day.txt合并后内容

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

<<<<<<<.mine

=======

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

=======

>>>>>>>.r37

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

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

图表 6 Day.txt解决冲突后内容

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

图表 7 Day.txt标记为已解决

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

3.2.2 复杂冲突解决

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

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

图表 8 冲突编辑工具

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

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

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

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

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

4. 加锁策略

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

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

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

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

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

5. 标签&分支

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

5.1 标签（tag）

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

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

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

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

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

5.2 分支（branch）

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

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

5.2.1 何时创建

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

 发布分支

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

 试验分支

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

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

5.2.2 合并分支

我们在分支上所修正的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. 项目初版本时，版本号为0.1.0；

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

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

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

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

例子：V1.0.1 Build090305 Rel111123

其它版本使用规则：

1. α（alphal）内部测试版

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

例子：V0.1.1 Build090305 alphal1

2. β（beta）外部测试版

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

例子：V0.1.2 Build090305 beta1

3. demo 演示版

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

例子：V0.1.3 Build090305 demo1

4. release 最终版

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

例子：V1.0.1 Build090305 Rel111123

3. 权限限制

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

4. 模块的版本维护

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

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

通常，很多Linux发行版已经自带了svn软件，安装系统时候选择即可。因此，本文并不讲解如何安装svn相关软件，而是重点总结一下如果使用svnserve服务器来构建自己的代码仓库，并且允许别人远程访问。本文的整个内容参考了svn手册。

一、新建并初始化版本库

1.新建代码仓库

# svnadmin create /home/myrepos

这样，我们就在/home目录下新建了版本库myrepos。

2.初始化代码仓库

#mkdir -p code/{branches,tags,trunk}

按照svn手册上的建议，我们版本库的布局采用branches/tags/trunk这样的三个目录。然后可以将代码直接拷贝的trunk目录，也可以随后采用svn add的方式添加。

#svn import code file: ///home/myrepos

将我们构造好的版本库布局（以及代码，如果已经拷贝到trunk下的话）提交到版本库。由于这里我们是在本地操作，因此可以直接使用file协议方式提交。格式为：file:// + 版本库绝对的路径

OK，到这里我们已经构建了一个本地版本库，可以再本地使用svn ci的方法得到版本库的副本了。如果前面只是提交了版本库布局，而没有提交代码的话，则可以通过如下命令，提交版本代码：

#svn co file: ///home/myrepos/trunk repos

通常只从主线目录trunk下取出源码，放在了新建的repos目录。然后可以将源码拷贝到repos目录。

执行以下两条命令将代码添加的版本库。

#svn add *

#svn ci * -m "Committed codes"

首先需要将拷贝的代码加入到当前的副本中，然后将代码提交到版本库。

二、配置并启动svnserve

1. 配置svnserve

这一步主要完成远程用户访问版本的权限。

在版本库目录下有个conf目录：home/myrepos/conf，该目录包含三个文件：authz，passwd，svnserve.conf。

（1）svnserve.conf

此文件重点的设置内容如下：

anon-access = read

auth-access = write

password-db = passwd

authz-db = authz

其中，anon-acces s和auth-access分别代表设置匿名用户和授权用户的访问权限。read代表只读，write代表可读可写，还有一个none，代表禁止访问。如果不想让匿名用户访问的话，可以设置anon-access = none。

password-db为保存版本库的用户名和密码，通常为conf目录下的passwd文件。

authz-db指向的文件，主要用于将用户进行分组，并赋予不同的组不同的权限。譬如有多个目录时，设置某个组的用户只可以访问其中的那些目录。

（2）passwd

如前面介绍，这个文件的主要内容如下

[users]

harry = harrysecret

sally = sallyssecret

以上两行就是可以访问版本库的用户名和密码。格式为：user = passwd。

（3）authz

[groups]

# harry_and_sally = harry,sally

# [/foo/bar]

# harry = rw

# * =

# [repository:/baz/fuz]

# @harry_and_sally = rw

# * = r

以上就是authz文件的格式。先给用户分组，然后分别设置每个组的工作目录以及权限等。

本文的讲解并未用到authz的配置。

2. 启动svnserve

#svnserve -d -r /home/

svnserve将以守护进程的方式运行。同时，通过-r选项指定了版本库的目录。这个目录可以是版本库的上级目录（/home），也可以是版本库的目录（/home/myrepos）。具体的区别会在后面讲到。当然，也可以不用-r指定。

三、远程访问svnserve。

假设版本服务器的地址为10.1.1.1，那么用户可以在远程linux端输入命令：

#svn checkout svn://10.1.1.1/myrepos myrepos

这样版本库的所有内容都被check出来，存放在当前目录myrepos下。这里相当于使用svn协议，不用搭建http服务器。

如果启动svnserve的时候，-r选项指定的是版本库的目录，譬如/home/myrepos，那么检出版本的时候，执行的命令为：

#svn checkout svn://10.1.1.1/ myrepos

如果启动svnserve是没有指定-r选项，则要输入版本库的绝对路径：

#svn checkout svn://10.1.1.1/home/myrepos myrepos

四、容易出现的问题

在访问svnserve时，遇到了不少的问题，大致总结一下：

1. 这一步最容易避免，一定要记得启动svnserve。

2. 记得要正确的修改配置文件svnserve.conf和passwd。

3. 保证版本库服务器没有配置限制远程访问svnserve的规则。有时在访问svn服务器的时候，会提示服务器积极拒绝链接。简单起见，可以看看iptables -L INPUT和iptables -L OUTPUT有没有限制访问的规则。

4. 要保证输入版本库的URL正确。

后记：

1. 版本库的初次导入可以采用多种方式：

（1）直接构建好版本库目录，并将源码拷贝的对应的位置，然后svn import即可；

（2）先用svn checkout取出版本，然后构建目录和源码，执行svn add 并且svn commit即可。

2. 导入或者提交文件类型的控制

svn客户端是可以配置忽略哪些些文件，比如说我们不想提交*.o之类的文件。那么可以通过设置svn:ignore或者global-ignore来进行过滤相关的文件。通常默认的情况就会过滤掉*.o, *.so,*.a等被svn认为是中间生成的文件。我本人使用的客服端不管是WIN的还是Linux的都是这种默认情况。

但是，如果有时基于某种需要，或者是导入一个别人之前维护的工程，里面有些*.so，*.a文件必须保留，那么如果在第一次import的时候全部导入呢？曾经问过有些朋友说，svn add或者svn import是可以直接把这种文件导入到版本库的。但是我个人进行测试的时候，确实导入不进去，除非你直接svn add这个文件，然后提交应该就可以了。

如果这样的文件比较多，而且比较分散，那么如何解决呢？看一下svn import和svn add这两个命令的帮助，都有--no-ignore选项。这个选项的功能就是执行相应动作的时候，不忽略任何文件。那么执行以下两条命令：

svn import [source] [repository] --no-ignore

或

svn add [source] --no-ignore

会自动将source目录下所有的内容全部import或者add。

因此，通过--no-ignore选项，可以满足提交一些特殊文件的需求。

3. 用一个旧版本的svnadmin创建的版本库，直接拷贝到另外一台svn版本比较高的PC上使用时，发现提示数据库版本不匹配。解决的方法：

（1）导出旧的版本库内容，包含版本信息

具体使用的命令为svnadmin dump, 详细使用方法参考手册。该命令的格式为：

svnadmin dump REPOS_PATH [-r LOWER[:UPPER]] [--incremental]

如果我将版本库完整的信息都倒出来的话，执行如下命令：

# svnadmin dump old_repos >repos.dump

默认版本库dump的时候是输出在终端的，通过重定下输出到repos.dump文件里面。该文件实际是文本文件。

（2）导入旧版本库的内容

在需要导入的位置，新建一个版本库

# svnadmin create new_repos

然后将repos.dump文件导入到新的版本库：

# svnadmin load new_repos <repos.dump

该命令成功执行完毕之后，新的版本库中已经包含了old_repos版本库中的所有版本内容。

svnadmin dump和svnadmin load命令都支持导入/导出某个指定revsion或者某个指定范围的所有revision。该部分后记参考了如下连接，在此表示感谢：

http://hi.baidu.com/primechen/blog/item/71a7a1dc2b981fe877c63841.html

Windows与Linux下SVN怎样使用?

本文分2个部分(包括Windows与Linux操作系统平台),第1部分:怎样安装 第2部分:怎样使用

-----------------------------------------第1部分:怎样安装-----------------------------------------

怎样安装分2种情况,第1种:在公司上班 第2种:在宿舍电脑

--------------------第1种:在公司上班--------------------

说明:通常SVN服务器是安装在windows上的,安装好后,客户端2种平台都能使用

Windows平台下

服务端与客户端:

通常这种情况,你想安装,公司都不会让你安装,一般是由公司内网管专业人士统一安装好,并给你分配好账户与密码,以及每个SVN下使用权限,所以这种情况你可以不用去管怎样安装了,只管怎样使用即可

linux平台下

服务端:即windows上的服务端

客户端:如果你在本机安装的Linux虚拟机,通常是自己安装的,不是公司网管安装的,安装办法如下:

1步即能安装:在linux下输入命令 sudo apt-get install subversion

即SVN,安装后同windows上SVN一样,只不过这里是输入命令而已

--------------------第2种:在宿舍电脑--------------------

Windows与Linux平台下

说实在的,宿舍就1台电脑.本来电脑就垃圾.而且还开着虚拟机,在开2个VS2010,就已经卡的要死.在来个SVN,估计会慢如蜗牛,其实大部分程序员也是只有一台电脑,安装SVN真的没必要.除非有多台电脑.SVN本质是为方便团队开发

-----------------------------------------第2部分:怎样使用-----------------------------------------

怎样使用要分2种情况,第1种:是Windows平台 第2种:是Linux平台

--------------------第1种:是Windows平台--------------------

1.更新

右键->SVN更新

2.提交(也可说成是上传)

第1步:进入要提交的SVN文件目录里面,导入文件

第2步:导入后,返回上一层目录,即返回到要提交的SVN文件目录,右键点击此SVN目录,弹出,提交,进入

第3步:进入提交对话框后,会显示2个编辑框,上面的编辑框是确认要提交的内容,下面的编辑框是你刚导入的文件内容,

你现在若是想提交刚才导入的内容,就把下面编辑框的内容用鼠标拖动到上面的编辑框,并按确定

若不想提交刚才导入的内容,直接按取消退出即可

3.导出

即怎样去掉SVN的专用标志,有的是对勾,有的是?号等等?

方法 1:在文件属性--->选择显示所有文件,这时文件里会出现1个.svn的文件目录,把它删掉即可.(文件目录多时,不推荐)

方法 2:在SVN右键--->导出,这时导出的文件不会带SVN标志了

4.删除

在SVN右键中,删除之后.要返回上一层目录,点提交.

删除信息在变更列表,要拖动到信息栏下,然后点确定

5.保存认证

每当电脑密码更改时,SVN以前保存的密码也会要更新,此时会弹出一个认证框,重新输入账号与新密码,在保存认证处打勾即可

--------------------第2种:是Linux平台--------------------

1.更新

命令:svn update

2.提交(也可说成是上传)

第1步:进入要提交的SVN文件目录里面,

第2步:添加要提交的目录用svn add *----------->注:(*代表添加文件、目录或符号链)

第3步:提交

(1)提交全部

svn ci -m"*"----------->m表示写注释,*代表注释内容

注:在LINUX上同一目录存在其它文件,svn ci提交时,只会提交SVN服务器已有的文件.如果想让同一目录下的其它文件也提交到SVN服务器,可以先通过svn add先添加此文件或文件夹等

(2)提交单个

svn ci -m"add select_area packet" Gateway_Handler.cpp

后面一个加上要提交的文件(记的把后缀名写上去).

提交成功后会提示

SendingGateway_Handler.cpp

Transmitting file data .

Committed revision 242.

3.保存认证

每当电脑密码更改时,SVN以前保存的密码也会要更新,此时会显示要输入密码,重新输入账号与新密码,最后会提示是否要保存密码(yes/no),选yes即可

4.下载

命令 svn co * (*代表下载地址,例如http://192.168.1.101/project/servers/command)

之后会在当前目录下,导出一个command文件夹,里面是SVN服务器上的文件

5.删除

svn del *(*为文件名,或文件)

6.查看修改后的操作是哪些

svn diff

---------------------------------------------------以下是摘抄的---------------------------------------------------

1、将文件checkout到本地目录

svn checkout path（path是服务器上的目录）

例如：svn checkout svn://192.168.1.1/pro/domain

简写：svn co

1、将文件checkout到本地目录

svn checkout path（path是服务器上的目录）

例如：svn checkout svn://192.168.1.1/pro/domain

简写：svn co

2、往版本库中添加新的文件

svn add file

例如：svn add test.PHP(添加test.php)

svn add *.php(添加当前目录下所有的php文件)

3、将改动的文件提交到版本库

svn commit -m “LogMessage“ [-N] [--no-unlock] PATH(如果选择了保持锁，就使用–no-unlock开关)

例如：svn commit -m “add test file for my test“ test.php

简写：svn ci

4、加锁/解锁

svn lock -m “LockMessage“ [--force] PATH

例如：svn lock -m “lock test file“ test.php

svn unlock PATH

5、更新到某个版本

svn update -r m path

例如：

svn update如果后面没有目录，默认将当前目录以及子目录下的所有文件都更新到最新版本。

svn update -r 200 test.php(将版本库中的文件test.php还原到版本200)

svn update test.php(更新，于版本库同步。如果在提交的时候提示过期的话，是因为冲突，需要先update，修改文件，然后清除svn resolved，最后再提交commit)

简写：svn up

6、查看文件或者目录状态

1）svn status path（目录下的文件和子目录的状态，正常状态不显示）

【?：不在svn的控制中；M：内容被修改；C：发生冲突；A：预定加入到版本库；K：被锁定】

2）svn status -v path(显示文件和子目录状态)

第一列保持相同，第二列显示工作版本号，第三和第四列显示最后一次修改的版本号和修改人。

注：svn status、svn diff和 svn revert这三条命令在没有网络的情况下也可以执行的，原因是svn在本地的.svn中保留了本地版本的原始拷贝。

简写：svn st

7、删除文件

svn delete path -m “delete test fle“

例如：svn delete svn://192.168.1.1/pro/domain/test.php -m “delete test file”

或者直接svn delete test.php 然后再svn ci -m ‘delete test file‘，推荐使用这种

简写：svn (del, remove, rm)

8、查看日志

svn log path

例如：svn log test.php 显示这个文件的所有修改记录，及其版本号的变化

9、查看文件详细信息

svn info path

例如：svn info test.php

10、比较差异

svn diff path(将修改的文件与基础版本比较)

例如：svn diff test.php

svn diff -r m:n path(对版本m和版本n比较差异)

例如：svn diff -r 200:201 test.php

简写：svn di

11、将两个版本之间的差异合并到当前文件

svn merge -r m:n path

例如：svn merge -r 200:205 test.php（将版本200与205之间的差异合并到当前文件，但是一般都会产生冲突，需要处理一下）

12、SVN 帮助

svn help

svn help ci

——————————————————————————

以上是常用命令，下面写几个不经常用的

——————————————————————————

13、版本库下的文件和目录列表

svn list path

显示path目录下的所有属于版本库的文件和目录

简写：svn ls

14、创建纳入版本控制下的新目录

svn mkdir: 创建纳入版本控制下的新目录。

用法: 1、mkdir PATH…

2、mkdir URL…

创建版本控制的目录。

1、每一个以工作副本 PATH 指定的目录，都会创建在本地端，并且加入新增

调度，以待下一次的提交。

2、每个以URL指定的目录，都会透过立即提交于仓库中创建。

在这两个情况下，所有的中间目录都必须事先存在。

15、恢复本地修改

svn revert: 恢复原始未改变的工作副本文件 (恢复大部份的本地修改)。revert:

用法: revert PATH…

注意: 本子命令不会存取网络，并且会解除冲突的状况。但是它不会恢复

被删除的目录

16、代码库URL变更

svn switch (sw): 更新工作副本至不同的URL。

用法: 1、switch URL [PATH]

2、switch –relocate FROM TO [PATH...]

1、更新你的工作副本，映射到一个新的URL，其行为跟“svn update”很像，也会将

服务器上文件与本地文件合并。这是将工作副本对应到同一仓库中某个分支或者标记的

方法。

2、改写工作副本的URL元数据，以反映单纯的URL上的改变。当仓库的根URL变动

(比如方案名或是主机名称变动)，但是工作副本仍旧对映到同一仓库的同一目录时使用

这个命令更新工作副本与仓库的对应关系。

17、解决冲突

svn resolved: 移除工作副本的目录或文件的“冲突”状态。

用法: resolved PATH…

注意: 本子命令不会依语法来解决冲突或是移除冲突标记；它只是移除冲突的

相关文件，然后让 PATH 可以再次提交。

18、输出指定文件或URL的内容。

svn cat 目标[@版本]…如果指定了版本，将从指定的版本开始查找。

svn cat -r PREV filename >filename (PREV 是上一版本,也可以写具体版本号,这样输出结果是可以提交的)

19、查找工作拷贝中的所有遗留的日志文件，删除进程中的锁。

当Subversion改变你的工作拷贝（或是.svn中的任何信息），它会尽可能的小心，在修改任何事情之前，它把意图写到日志文件中去，然后执行log文件中的命令，然后删掉日志文件，这与分类帐的文件系统架构类似。如果Subversion的操作中断了（举个例子：进程被杀死了，机器死掉了），日志文件会保存在硬盘上，通过重新执行日志文件，Subversion可以完成上一次开始的操作，你的工作拷贝可以回到一致的状态。

这就是svn cleanup所作的：它查找工作拷贝中的所有遗留的日志文件，删除进程中的锁。如果Subversion告诉你工作拷贝中的一部分已经“锁定”了，你就需要运行这个命令了。同样，svn status将会使用L 显示锁定的项目：

$ svn status LsomedirM somedir/foo.c $ svn cleanup$ svn statusM somedir/foo.c20、拷贝用户的一个未被版本化的目录树到版本库。svn import命令是拷贝用户的一个未被版本化的目录树到版本库最快的方法，如果需要，它也要建立一些中介文件。

$ svnadmin create /usr/local/svn/newrepos $ svn import mytree file:///usr/local/svn/newrepos/some/project Adding mytree/foo.c Adding mytree/bar.c Adding mytree/subdir Adding mytree/subdir/quux.h Committed revision 1.

在上一个例子里，将会拷贝目录mytree到版本库的some/project下：

$ svn list file:///usr/local/svn/newrepos/some/project bar.c foo.c subdir/

注意，在导入之后，原来的目录树并没有转化成工作拷贝，为了开始工作，你还是需要运行svn checkout导出一个工作拷贝。

另附：为SVN加入Email通知

可以通过Subversion的Hook脚本的方式为SVN加入邮件列表功能

编译安装了Subversion后 在源码的tools 下有一个comm-email.pl的Perl脚本，在你的档案目录下有一个hooks目录，进入到hooks目录把post-commit.tmpl 改名为post-commit并给它可执行的权限。

更改post-commit脚本 把comm-email.pl脚本的决对路径加上，否则 SVN找不到comm-email.pl

REPOS="$1"

REV="$2"

/usr/local/svn/resp/commit-email.pl "$REPOS" "$REV" email@address1.com email@address2.com

#log-commit.py --repository "$REPOS" --revision "$REV"

最后一行是用来记日志的 我不用这个功能 所以注释掉了.

-------------------------------------------------------------------------------------------------------

注意:为保证代码安全.最好要备份.每个操作都要谨慎

---