svn命令行解决冲突

A. windows 怎么用svn命令

1、Windows下命令行工具：

发现原来安装的tortoisesvn已经集成到shell中，不能在命令行下使用。

下载Apache Subversion command line tools，这是一个可以在cmd下使用的命令行工具，解压后把里面bin目录这个路径添加到环境变量的path，这样在cmd下就可以使用了，和linux下使用svn的习惯一样了。

目录约定：

• /trunck：开发主线

• /branches：支线副本

• /tags：标签副本（一旦创建，不允许修改）

1）使用trunk作为主要的开发目录

一般的，我们的所有的开发都是基于trunk进行开发，当一个版本（release）开发告一段落（开发、测试、文档、制作安装程序、打包等结束后），代码处于冻结状态（人为规定，可以通过hook来进行管理）。此时应该基于当前冻结的代码库，打tag。

当下一个版本/阶段的开发任务开始时，继续在trunk进行开发。此时，如果发现了上一个已发行版本（Released Version）有一些bug，或者一些很急迫的功能要求，而正在开发的版本（Developing Version）无法满足时间要求，这时候就需要在上一个版本上进行修改了。解决方法是基于发行版对应的tag，做相应的分支（branch）进行开发。

2）下图为struts2的SVN仓库目录：




3、常用命令

svn help

svn --version

svn --version --quiet 只显示版本号

svn checkout 地址


svn add 文件或者文件夹 增加本地数据到服务器

svn commit / svn ci -m “注释” 文件名 提交代码，要先add才commit

svn update / svn up不必跟特定的文件或目录，也可以自己指定需要更新的文件或目录。每次commit或者改动之前最好更新一下。

svn log

svn delete 文件名

svn resolve 路径 --accept working 解决冲突

http://zccst.iteye.com/blog/1765519

svn switch 远程路径 版本切换

svn list路径/svn ls 列出版本库下的文件和目录

svn merge -r m:n 路径 合并文件，从版本号m到版本号n的远程分支都合并到当前分支中

svn info 确认工作目录的svn信息

svn diff -r m:n 路径 对版本m和版本n比较差异

svn cleanup 为失败的失误清场

svn status -v 在本地进行代码修改，检查修改状态

svn import 远程路径 --message “message” 将当前路径下文件导入到版本库中

svn export 远程路径 导出一份干净的项目

svn move/ svn mv 原文件名 新文件名 重命名

svn mkdir 文件名

svn / svn cp 源文件路径 新文件路径

svn revert 文件名 只能恢复未提交之前的操作


若要还原已提交的改动：只能用旧文件覆盖新文件。操作如下：

1）sun up 让本地工作拷贝更新到最新状态


2）svn log your_file_path 查看文件日志，这时候提交时填写的说明信息就派上用场了

3）svn diff -r 旧修订版序号:新修订版序号 your_file_path 查看两个修订版之间的不同。


4）决定用哪个旧的修订版号后，用旧的修订版号文件覆盖新的修订版号文件。svn merge -r 新修订版序号:旧修订版序号 your_file_path


5）svn commit -m "恢复到某修订版（某修订版作废）"


本地的版本叫做working

4、关于merge

• branch主要用于新功能的开发

• 合并发生在本地working ，只要你不提交就不会影响到repository

• 合并前一定要先update、commit，保证不会out of day，并将本地的修改保存到repository

• branch和trunk并行开发的过程中，要经常同步，将trunk的修改合并到branch，合并时选择"Merge a range of revision"

• branch最后合并回trunk时，merge type选择"Reintegrate a branch"

  不管是从trunk合并到branch还是最终从branch合并回trunk，在每次合并前最好先update，然后将本地的修改先全部commit，保护好现场，万一合并不理想随时都可以reverthttp://blog.csdn.net/eggcalm/article/details/6606520
  

http://zhengkun.readthedocs.org/zh_CN/latest/2014/02/07/svn-usage/

5、关于解决冲突

发生冲突之后会出现三个临时文件：

XXX.mine XXX.r1 XXX.r2

一旦解决了冲突，需用svn resolved让subversion知道，这样就会删除这三个临时文件，冲突状态解决。

三种解决方式：

• 手工合并冲突：需要将冲突标志删除
  

• 用某一个临时文件覆盖自己的工作文件

• 用svn revert 放弃本地修改，不需要执行resolved

B. svn 命令行怎么解决冲突

工程师A修改了a.txt的第一行，提交了。
工程师B也修改了a.txt的第一行，然后执行svn up，这时SVN提示了：（以下，你开始扮演工程师B的角色了）
$ svn up
在 “a.txt” 中发现冲突。
选择: (p) 推迟，(df) 显示全部差异，(e) 编辑,
(mc) 我的版本, (tc) 他人的版本,
(s) 显示全部选项:

我一般选择p（推迟），即引入冲突到本地，不过不会影响到SVN服务器端，可以放心。

OK，开始解决冲突了。

这时，会生成几个文件：

a.txt a.txt.mine a.txt.r6328 a.txt.r6336

其中a.txt中包含了工程师A、B的所有修改，以<<<<<<<、=======、>>>>>>>分隔。

a.txt.mine是工程师B的修改，也就是未update前的a.txt。

a.txt.r6328 是工程师A提交前的版本，即未导致冲突的版本。

a.txt.r6336是工程师A提交后的版本，即导致冲突的版本。

一般，查看a.txt就可以看到冲突的详情了：

[yicheng@chengyi svntest]$ cat a.txt

<<<<<<< .mine

i also modify ,agndagnagasdg;

=======

i modify this line;

>>>>>>> .r6336

以上，<<<<<<< .mine和=======之间是工程师B（当前的“你”）修改的内容，=======与>>>>>>> .r6336之间是工程师A修改的内容。这时，最好的办法是，叫上工程师A，你们一起确定这些修改是否都需要，是否相互兼容，然后留下需要的部分，删 除<<<<<<< .mine、=======和>>>>>>> .r6336。

然后，测试，测试！确定没问题之后，就可以告诉SVN，你解决冲突了：

svn resolve –accept working a.txt (该命令会删除a.txt.mine a.txt.r6328 a.txt.r6336）

svn ci -m ’some comment’ a.txt

这里需要注意的是，a.txt.mine a.txt.r6328 a.txt.r6336这几个文件的存在代表着有冲突产生。如果不解决冲突，就手工删除它们，SVN服务器也会很傻的认为你解决了冲突，允许你继续之后 的工作。但是，冲突依旧存在，你的a.txt中不但有别人的修改，还有那些讨厌的<=>符号。

在冲突未解决前，试图提交代码是肯定会失败的：

$ svn ci -m ”

svn: 提交失败(细节如下):

svn: 提交终止: “/path/to/svntest/a.txt” 处于冲突状态
在使用svn update 的时候，会出现如下一些信息：
$ svn update
U INSTALL
G README
C bar.c
Updated to revision 46.

那么，U 开头的信息提示你，这个文件在你本地没有修改过，文件已经根据版本库的新版本更新了。G 开头的信息提示你，这个文件在你本地已经修改过，但是和版本库中对应的版本并没有冲突的地方，svn已经合并更新了。而C 开头的信息提示你，这个文件有点麻烦，你在本地的修改和版本库中的版本修改的地方重叠了，也就是说，你修改了某一行，你的同事也修改了同一行。这个就需要你自己手工去解决了。当冲突发生时，要注意到有三件事情可以帮助你解决问题。

C. svn eclipce怎么解决冲突

在项目上右键选择team-与资源库同步

打开如下的界面，team synchronizing模式下的synchronize界面下，如果有红色的标示，标明内容冲突了

双击打开红色标示的文件，左边为你本机的版本，右边为最新的版本。如果内容没有红色的标示，就是内容不冲突，可以先更新，后提交。但是有红色的时候就是内容有冲突，根据红色提示先还原本机的红色的部分，更新后再提交

红色的部分处理完之后，蓝色的为需要更新的内容，右键更新就可以了，也可以双击查看内容

灰色的为需要提交的内容，右键提交就可以了

提交的内容中有些文件时不用提交的，是本机的环境配置的文件，提交了会影响其他同事

D. 同步svn，xib有冲突怎么解决

很简单，先把文件拷贝到本地，然后右键点冲突的文件，找到svn中的还原，然后再把你本地刚刚拷贝的那个文件和svn上的文件对比，然后看你修改了那些地方，然后再svn上最新版本的基础上进行修改，然后提交。
如果你不想别人也修改你正在修改的文件，你可以在修改前直接锁定那个文件，直到你提交以后再解锁。这就不会冲突了

E. svn出现黄色感叹号怎么办

如果您是指电脑宽带网络连接图标出现黄色叹号导致无法上网，一般是由于IP地址冲突导致，建议您可打开【网络共享中心】，选择【更改适配器设置】，右键本地连接属性，双击ipv4，选择自动获取ip，然后打开【运行】，输入CMD，在命令提示符下输入【ipconfig\new】重新获取ip地址尝试。

F. svn 命令行怎么解决冲突

1.svn ci -m "update"
svn: Commit failed (details follow):
svn: Aborting commit: 'test.log' remains in conflict
2.使用svn resolved test.log
3.svn ci -m "update"
这个时候应该可以提交了
4.svn rm test.log
删除掉这个文件
5.svn ci -m "update"
再次提交
这个时候服务器上就没有这个文件了。
在其他的服务器终端上如果遇到这个问题的时候重复这个操作。

G. 更新本地文件到SVN中时有冲突如何解决

有冲突一般是可能本地与主SVN服务器都修改了同一处地方。
解决方法,可先把本地的冲突文件删除掉，再重新从SVN更新下来到本地。然后你再修改提交，应该就没有问题了。
所以SVN协同工作时 一定要养成先更新 再提交的好习惯。希望可以帮到你。

H. svn 详解

1、检出

svncohttp://路径(目录或文件的全路径)[本地目录全路径]

--username 用户名 --password 密码svncosvn://路径(目录或文件的全路径)[本地目录全路径]--username 用户名 --password 密码

svncheckouthttp://路径(目录或文件的全路径)[本地目录全路径] --username用户名

svncheckoutsvn://路径(目录或文件的全路径)[本地目录全路径]--username用户名

注：如果不带--password 参数传输密码的话，会提示输入密码，建议不要用明文的--password 选项。

其中 username 与 password前是两个短线，不是一个。

不指定本地目录全路径，则检出到当前目录下。

例子：

svn co svn://localhost/测试工具/home/testtools--usernamewzhnsc

svn co http://localhost/test/testapp--usernamewzhnsc

svn checkout svn://localhost/测试工具/home/testtools--usernamewzhnsc

svncheckouthttp://localhost/test/testapp--usernamewzhnsc

2 、 导出(导出一个干净的不带.svn文件夹的目录树 )

svnexport[-r 版本号]http://路径(目录或文件的全路径) [本地目录全路径]--username用户名

svnexport[-r 版本号]svn://路径(目录或文件的全路径) [本地目录全路径]--username用户名

svnexport本地检出的(即带有.svn文件夹的)目录全路径要导出的本地目录全路径

注：第一种从版本库导出干净工作目录树的形式是指定URL，

如果指定了修订版本号，会导出相应的版本，

如果没有指定修订版本，则会导出最新的，导出到指定位置。

如果省略本地目录全路径，URL的最后一部分会作为本地目录的名字。

第二种形式是指定 本地检出的目录全路径 到 要导出的本地目录全路径，所有的本地修改将会保留，

但是不在版本控制下(即没提交的新文件，因为.svn文件夹里没有与之相关的信息记录)的文件不会拷贝。

例子：

svn export svn://localhost/测试工具/home/testtools--usernamewzhnsc

svn export svn://localhost/test/testapp--usernamewzhnsc

svn export /home/testapp/home/testtools

3、添加新文件

svnadd文件名

注：告诉SVN服务器要添加文件了，还要用svn commint -m真实的上传上去！

例子：

svn addtest.php＜－添加test.php

svn commit -m“添加我的测试用test.php“ test.php

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

svn commit -m“添加我的测试用全部php文件“ *.php

4、提交

svncommit-m“提交备注信息文本“[-N][--no-unlock]文件名

svnci-m“提交备注信息文本“[-N][--no-unlock]文件名

必须带上-m参数，参数可以为空，但是必须写上-m

例子：

svn commit -m“提交当前目录下的全部在版本控制下的文件“ *＜－注意这个*表示全部文件

svn commit -m“提交我的测试用test.php“ test.php

svn commit -m“提交我的测试用test.php“-N --no-unlocktest.php＜－保持锁就用–no-unlock开关

svn ci -m“提交当前目录下的全部在版本控制下的文件“ *＜－注意这个*表示全部文件

svn ci -m“提交我的测试用test.php“ test.php

svn ci -m“提交我的测试用test.php“-N --no-unlocktest.php＜－保持锁就用–no-unlock开关

5、更新文件

svnupdate

svnupdate-r修正版本文件名

svnupdate文件名

例子：

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

svn update -r200 test.cpp＜－将版本库中的文件 test.cpp 还原到修正版本（revision）200

svn updatetest.php＜－更新与版本库同步。

提交的时候提示过期冲突，需要先 update 修改文件，

然后清除svn resolved，最后再提交commit。

6、删除文件

svndeletesvn://路径(目录或文件的全路径) -m “删除备注信息文本”

推荐如下操作：

svndelete文件名

svnci-m“删除备注信息文本”

例子：

svn delete svn://localhost/testapp/test.php-m“删除测试文件test.php”

推荐如下操作：

svn deletetest.php

svn ci -m“删除测试文件test.php”

7、加锁/解锁

svnlock-m“加锁备注信息文本“[--force]文件名

svnunlock文件名

例子：

svn lock -m“锁信测试用test.php文件“ test.php

svn unlocktest.php

8、比较差异

svndiff文件名

svndiff-r修正版本号m:修正版本号n文件名

例子：

svn difftest.php＜－将修改的文件与基础版本比较

svn diff -r200:201 test.php＜－对 修正版本号200 和 修正版本号201 比较差异

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

svn st目录路径/名

svn status 目录路径/名＜－目录下的文件和子目录的状态，正常状态不显示

【?：不在svn的控制中；M：内容被修改；C：发生冲突；

A：预定加入到版本库；K：被锁定】

svn-v 目录路径/名

svn status -v 目录路径/名＜－显示文件和子目录状态

【第一列保持相同，第二列显示工作版本号，

第三和第四列显示最后一次修改的版本号和修改人】

注：svn status、svn diff和 svn revert这三条命令在没有网络的情况下也可以执行的，

原因是svn在本地的.svn中保留了本地版本的原始拷贝。

10、查看日志

svnlog文件名

例子：

svn logtest.php＜－显示这个文件的所有修改记录，及其版本号的变化

11、查看文件详细信息

svninfo文件名

例子：

svn infotest.php

12、SVN 帮助

svnhelp＜－全部功能选项

svnhelpci＜－ 具体功能的说明

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

svnlistsvn://路径(目录或文件的全路径)

svnlssvn://路径(目录或文件的全路径)

例子：

svn list svn://localhost/test

svn ls svn://localhost/test＜－显示svn://localhost/test目录下的所有属于版本库的文件和目录

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

svnmkdir目录名

svnmkdir-m"新增目录备注文本"http://目录全路径

例子：

svn mkdirnewdir

svn mkdir -m"Making a new dir."svn://localhost/test/newdir

注：添加完子目录后，一定要回到根目录更新一下，不然在该目录下提交文件会提示“提交失败”

svn update

注：如果手工在checkout出来的目录里创建了一个新文件夹newsubdir，

再用svn mkdirnewsubdir命令后，SVN会提示：

svn: 尝试用 “svn add”或 “svn add --non-recursive”代替？

svn: 无法创建目录“hello”: 文件已经存在

此时，用如下命令解决：

svn add --non-recursivenewsubdir

在进入这个newsubdir文件夹，用ls -a查看它下面的全部目录与文件，会发现多了：.svn目录

再用 svn mkdir -m "添hello功能模块文件" svn://localhost/test/newdir/newsubdir 命令，

SVN提示：

svn: File already exists: filesystem '/data/svnroot/test/db', transaction '4541-1',

path '/newdir/newsubdir '

15、恢复本地修改

svnrevert[--recursive]文件名

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

例子：

svn revertfoo.c＜－丢弃对一个文件的修改

svn revert --recursive.＜－恢复一整个目录的文件，. 为当前目录

16、把工作拷贝更新到别的URL

svnswitchhttp://目录全路径本地目录全路径

例子：

svn switch http://localhost/test/456 .＜－ (原为123的分支)当前所在目录分支到localhost/test/456

17、解决冲突

svnresolved[本地目录全路径]

例子：

$ svn update

C foo.c

Updated to revision 31.

如果你在更新时得到冲突，你的工作拷贝会产生三个新的文件：

$ ls

foo.c

foo.c.mine

foo.c.r30

foo.c.r31

当你解决了foo.c的冲突，并且准备提交，运行svn resolved让你的工作拷贝知道你已经完成了所有事情。

你可以仅仅删除冲突的文件并且提交，但是svn resolved除了删除冲突文件，还修正了一些记录在工作拷贝管理区域的记录数据，所以我们推荐你使用这个命令。

18、不checkout而查看输出特定文件或URL的内容

svncathttp://文件全路径

例子：

svn cat http://localhost/test/readme.txt

19、新建一个分支

svn branchA branchB-m "make B branch" // 从branchA拷贝出一个新分支branchB

20、合并内容到分支merge

svn mergebranchA branchB// 把对branchA的修改合并到分支branchB

I. svn如何解决分支冲突

1、 如何产生冲突

当开发人员A和开发人员B从版本库同时检出文档1.txt，而A和B同时修改了1.txt的同一地方，后提交的一方会在拷贝副本中产生冲突。

两个工作拷贝，A拷贝中文件1.txt内容为

dfqerq
123dfwre

B拷贝中文件1.txt内容为

dfqerq
123erwrq

在B版本提交之前版本库上的1.txt（base版本）内容为

dfqerq

B拷贝先提交版本到版本库中，以至于最新版本内容变为

dfqerq
123erwrq

此时A版本也提交则会产生冲突，无法提交，需要先svn

update，此时会在A拷贝中产生三个临时文件1.txt.rNew\1.txt.rOld\1.txt.mine，其中1.txt.rNew是最新版
本，1.txt.rOld是base版本，1.txt.mine是A作者修改后的版本，在此例中内容为

dfqerq
123dfwre

而update之后A拷贝中的1.txt内容为

<<<<<<< .mine
dfqerq
123dfwre=======
dfqerq
123erwrq>>>>>>> .r18

其中<<<<<<< .mine与=======之间表示A修改后的内容，=======与>>>>>>> .r18之间是版本服务器上的版本

2、解决冲突

第一种，利用update的选项进行冲突解决，也就是说不管当前拷贝副本是否是最新版本，都使用—accept参数作为冲突处理方式

–accept ARG : specify automatic conflict resolution action
(‘postpone’, ‘base’, ‘mine-conflict’,
‘theirs-conflict’, ‘mine-full’, ‘theirs-full’,
‘edit’, ‘launch’)

(p) postpone – mark the conflict to be resolved later //让文件在更新完成之后保持冲突状态。
(df) diff-full – show all changes made to merged file //使用标准区别格式显示base修订版本和冲突文件本身的区别。
(e) edit – change merged file in an editor //用你喜欢的编辑器打开冲突的文件，编辑器是环境变量EDITOR设置的。
(r) resolved – accept merged version of file //完成文件编辑之后，通知svn你已经解决了文件的冲突，它必须接受当前的内容—从本质上讲就是你已经“解决了”冲突。
(mf) mine-full – accept my version of entire file (ignore their change//丢弃新从服务器接收的变更，并只使用你查看文件的本地修改。
(tf) theirs-full – accept their version of entire file (lose my changes)//丢弃你对查看文件的本地修改，只使用从服务器新接收的变更。
(l) launch – launch external tool to resolve conflict//启动一个外置程序来执行冲突解决，这需要一些预先的准备。
(h) help – show this list //显示所有在冲突解决时可能使用的命令。

第二种，在update时并不处理冲突，利用svn resolve解决冲突

1、利用svn resolve –accept base选择base版本，即1.txt.rOld作为最后提交的版本

–accept ARG : specify automatic conflict resolution source
(‘base’, ‘working’, ‘mine-conflict’,
‘theirs-conflict’, ‘mine-full’, ‘theirs-full’)

2、手工修改1.txt文件，然后将当前拷贝即1.txt作为最后提交的版本

svn resolve –accept working 1.txt

3、svn resolve –accept theirs-full 1.txt 使用1.txt.rNew作为最后提交的版本

4、svn resolve –accept mine-full 1.txt 使用1.txt.mine作为最后提交的版本

5、svn resolve –accept mine-conflict 1.txt 使用1.txt.mine的冲突部分作为最后提交的版本

5、svn resolve –accept theirs-conflict 1.txt 使用1.txt.rNew的冲突部分作为最后提交的版本

第三种，使用svn revert取消变更

（以上文章来源：http://blog.sina.com.cn/s/blog_65fd4c1e0100h2cg.html）

－－－－－

前两天在解决冲突时用到了svn resolve这个命令，找到这篇文章主要是因为他对–accept参数的说明比较全

比官方的文档更详细。

svn文件冲突,树冲突详解

解决冲突

偶尔，当你从版本库更新、合并文件时，或者切换工作副本至一个不同的 URL 时你会遇到冲突。有两种冲突:

文件冲突

当两名(或更多)开发人员修改了同一个文件中相邻或相同的行时就会发生文件冲突。

树冲突

当一名开发人员移动、重命名、删除一个文件或文件夹，而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。

文件冲突

当两名或更多开发人员修改了同一个文件中相邻或相同的行时就会发生文件冲突。由于 Subversion 不知道你的项目的具体情况，它把解决冲突的工作留给了开发人员。一旦出现冲突，你就应该打开有问题的文件，查找以字符串<<<<<<<开头的行。有冲突的区域用如下的方式标记:

<<<<<<< 文件名
你的修改
=======
合并自版本库中的代码
>>>>>>> 版本

对于每个冲突的文件 Subversion 在你的目录下放置了三个文件:

文件名.ext.mine

这是你的文件，在你更新你的工作副本之前存在于你的的工作副本中——也就是说，没有冲突标志。这个文件除了你的最新修改外没有别的东西。

文件名.ext.r旧版本

这是在你更新你的工作副本之前的基础版本(BASE revision)文件。也就是说，它是在你做最后修改之前所检出的文件。

文件名.ext.r新版本

这个文件是当你更新你的工作副本时，你的 Subversion 客户端从服务器接收到的。这个文件对应于版本库中的最新版本。

你可以通过TortoiseSVN → 编辑冲突运行外部合并工具/冲突编辑器，或者你可以使用任何别的编辑器手动解决冲突。你需要冲定哪些代码是需要的，做一些必要的修改然后保存。

然后，执行命令TortoiseSVN → 已解决并提交人的修改到版本库。需要注意的是已解决命令并不是真正的解决了冲突，它只是删除了filename.ext.mine和filename.ext.r*两个文件，允许你提交修改。

如果你的二进制文件有冲突，Subversion不会试图合并文件。本地文件保持不变(完全是你最后修改时的样子)，但你会看到filename.ext.r*文件。如果你要撤消你的修改，保留版本库中的版本，请使用还原(Revert)命令。如果你要保持你的版本覆盖版本库中的版本，使用已解决命令，然后提交你的版本。

你可以右击父文件夹，选择TortoiseSVN → 已解决...，使用“已解决”命令来解决多个文件。这个操作会出现一个对话框，列出文件夹下所有有冲突的文件，你可以选择将哪些标记成已解决。

树冲突

当一名开发人员移动、重命名、删除一个文件或文件夹，而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。有很多种不同的情形可以导致树冲突，而且不同的情形需要不同的步骤来解决冲突。

当一个文件通过 Subversion 在本机删除后，文件也从本机文件系统中删除。因此即使它是树冲突的一部分，却既不能显示冲突的叠加图标也不能通过右键单击来解决冲突。使用检查修改对话框来获得编辑冲突选项。

TortoiseSVN 能够协助找到合并更改的正确位置，但是需要作一些额外的工作来整理冲突。请牢记: 当进行一次更新操作后，工作副本的基础文件将会包括每一个项目在执行更新操作时版本库中的版本。如果你在进行更新后再撤销更改，工作副本将返回到版本库的 状态，而不是你开始进行更改前的状态。

本地删除，当更新时有更改进入

开发人员 A 修改 Foo.c 并将其提交至版本库中

开发人员 B 同时在他的工作副本中将文件 Foo.c 改名为 Bar.c，或者仅仅是删除了 Foo.c 或它的父文件夹。

更新开发人员 B 的工作副本会导致树冲突:

在工作副本中，Foo.c 被删除了，但是被标记为树冲突。

如果冲突是由于更改文件名引起的而不是删除文件引起的，那么 Bar.c 被标记为添加，但是其中却不包括开发人员 A 修改的内容。

开发人员 B 现在必须做出选择是否保留开发人员 A 的更改。在更改文件名的案例中，他可以将 Foo.c 的更改合并到改名后的文件 Bar.c 中去。对于删除文件或文件夹的案例中，他可以选择保留包含开发人员 A 更改内容的项目并放弃删除操作。或什么也不做而直接将冲突标记为已解决，那样他实际上丢弃了开发人员 A 的更改。

如果 TortoiseSVN 能够找到被改名为 Bar.c 的原始文件，冲突编辑对话框将可以合并更改。这取决于在什么地方调用更新操作，它也许不能找到原始文件。

本地更改，当更新时有删除进入

开发人员 A 将文件 Foo.c 改名为 Bar.c 并将其提交至版本库中。

开发人员 B 在他的工作副本中修改文件 Foo.c。

或者在一个文件夹改名的案例中...

开发人员 A 将父文件夹 FooFolder 改名为 BarFolder 并将其提交至版本库中。

开发人员 B 在他的工作副本中修改文件 Foo.c。

更新开发人员 B 的工作副本会导致树冲突。对于一个简单的文件冲突:

Bar.c 被当作一个正常文件添加到工作副本中。

Foo.c 被标记为添加(包括其历史记录)并且产生树冲突。

对于一个文件夹冲突:

BarFolder 被当作一个正常文件夹添加到工作副本中。

FooFolder 被标记为添加(包括其历史记录)并且产生树冲突。

Foo.c 被标记为已修改。

开发人员 B 现在需要做出决定是否接受开发人员 A 作出的结构改变并且合并她的更改到新结构下适当的文件中，或者直接放弃开发人员 A 的更改并保留本地文件。

要合并她的本机更改到新布局中，开发人员 B 必须先找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以使用日志对话框来完成这个任务。更改必须要手工合并，因为没有办法自动的或者简单的完成此操作。一旦更改移植完毕，冲突的路径就是多余的并且可以删除。在此案例中，使用冲突编辑对话框中的删除按钮进行清理并将冲突标记为已解决。

如果开发人员 B 认为 A 的更改是错误的，那么在冲突编辑对话框中她必须选择保留按钮。这样就会标记冲突的文件/文件夹为已解决，但是需要手工删除开发人员 A 的更改。又是通过日志对话框帮助追踪哪些文件移动了。

本地删除，当更新时有删除进入

开发人员 A 将文件 Foo.c 改名为 Bar.c 并将其提交至版本库中。

开发人员 B 将文件 Foo.c 改名为 Bix.c

更新开发人员 B 的工作副本会导致树冲突:

Bix.c 被标记为添加(包括其历史记录)。

Bar.c 被添加到工作副本中，其状态为‘正常’。

Foo.c 被标记为删除并且产生一个树冲突。

要解决这个冲突，开发人员 B 必须找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以使用日志对话框来完成这个任务。

然后，开发人员 B 需要决定 Foo.c 的新文件名中的哪一个需要保留 - 开发人员 A 改的那个还是他自己改的那个。

在开发人员 B 手工解决冲突后，使用冲突编辑对话框中的按钮将树冲突标记为已解决。

本地缺少，当合并时有更改进入

开发人员 A 在主干上工作，修改 Foo.c 并将其提交至版本库中

开发人员 B 在分支上工作，将 Foo.c 改名为 Bar.c 并将其提交至版本库中

合并开发人员 A 的主干更改到开发人员 B 的分支工作副本会导致树冲突:

Bar.c 已经存在于工作副本中，其状态为‘正常’。

Foo.c 被标记为缺少并产生树冲突。

要解决这个冲突，开发人员 B 要在冲突编辑对话框中标记文件为已解决，这样就会将其从冲突列表中删除。她接下来需要决定是否将缺少的文件 Foo.c 从版本库中复制到工作副本中，是否将开发人员 A 的对 Foo.c 的更改和合并到改名后的 Bar.c 或者是否通过标记冲突为已解决来忽略更改什么事也不做。

注意，如果你将缺少的文件从版本库中复制到工作副本中然后再标记为已解决，你复制下来的文件将被再次删除。你必须先解决冲突。

本地更改，当合并时有删除进入

开发人员 A 在主干上工作，将 Foo.c 改名为 Bar.c 并将其提交至版本库中

开发人员 B 在分支上工作，修改 Foo.c 并将其提交至版本库中

当文件夹改名时有类似的案例，但是在 Subversion 1.6 中还未被识别...

开发人员 A 在主干上工作，将父文件夹 FooFolder 改名为 BarFolder 并将其提交至版本库中。

开发人员 B 在分支上工作，在她的工作副本中修改 Foo.c 。

合并开发人员 A 的主干更改到开发人员 B 的分支工作副本会导致树冲突:

Bar.c 被标记为添加。

Foo.c 被标记为修改并产生树冲突。

开发人员 B 现在需要做出决定是否接受开发人员 A 作出的结构改变并且合并她的更改到新结构下适当的文件中，或者直接放弃开发人员 A 的更改并保留本地文件。

要合并她的本机更改到新布局中，开发人员 B 必须先找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以通过适用于合并源码的日志对话框来完成这个任务。冲突编辑器仅显示工作副本的日志因为它不知道将哪个路 径的更改合并进来，所以你需要自己找到它。更改必须要手工合并，因为没有办法自动的或者简单的完成此操作。一旦更改移植完毕，冲突的路径就是多余的并且可 以删除。在此案例中，使用冲突编辑对话框中的删除按钮进行清理并将冲突标记为已解决。

如果开发人员 B 认为 A 的更改是错误的，那么在冲突编辑对话框中她必须选择保留按钮。这样就会标记冲突的文件/文件夹为已解决，但是需要手工删除开发人员 A 的更改。又是通过日志对话框帮助追踪哪些文件移动了。

本地删除，当合并时有删除进入

开发人员 A 在主干上工作，将 Foo.c 改名为 Bar.c 并将其提交至版本库中

开发人员 B 工作在分之上，将 Foo.c 改名为 Bix.c 并将其提交至版本库中

合并开发人员 A 的主干更改到开发人员 B 的分支工作副本会导致树冲突:

Bix.c 被标记为正常(未修改)状态。

Bar.c 被标记为添加(包括其历史记录)。

Foo.c 被标记为缺少并且产生树冲突。

要解决这个冲突，开发人员 B 必须先找出冲突的文件 Foo.c 经过改名/移动后在版本库中的新文件名是什么。可以通过适用于合并源码的日志对话框来完成这个任务。冲突编辑器仅显示工作副本的日志因为它不知道将哪个路径的更改合并进来，所以你需要自己找到它。

然后，开发人员 B 需要决定 Foo.c 的新文件名中的哪一个需要保留 - 开发人员 A 改的那个还是他自己改的那个。

在开发人员 B 手工解决冲突后，使用冲突编辑对话框中的按钮将树冲突标记为已解决。