svn 冲突的产生与解决1、如何产生冲突当开发人员A和开发人员B从版本库同时检出文档1.txt，而A和B同时修改了1.txt的同一地方，后提交的一方会在拷贝副本中产生冲突。
两个工作拷贝，A拷贝中文件1.txt内容为dfqerq123dfwreB拷贝中文件1.txt内容为dfqerq123erwrq在B版本提交之前版本库上的1.txt（base版本）内容为dfqerqB拷贝先提交版本到版本库中，以至于最新版本内容变为dfqerq123erwrq此时A版本也提交则会产生冲突，无法提交，需要先svn update，此时会在A 拷贝中产生三个临时文件1.txt.rNew\1.txt.rOld\1.txt.mine，其中1.txt.rNew是最新版本，1.txt.rOld是base版本，1.txt.mine是A作者修改后的版本，在此例中内容为dfqerq123dfwre而update之后A拷贝中的1.txt内容为<<<<<<< .minedfqerq123dfwre=======dfqerq123erwrq>>>>>>> .r18其中<<<<<<< .mine与=======之间表示A修改后的内容，=======与>>>>>>> .r18之间是版本服务器上的版本2、解决冲突第一种，利用update的选项进行冲突解决，也就是说不管当前拷贝副本是否是最新版本，都使用—accept参数作为冲突处理方式–accept ARG : specify automatic conflict resolution action(‗postpone‘, ‗base‘, ‗mine-conflict‘,‗theirs-confl ict‘, ‗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.txt3、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取消变更（以上文章来源：/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 能够协助找到合并更改的正确位置，但是需要作一些额外的工作来整理冲突。
请牢记: 当进行一次更新操作后，工作副本的基础文件将会包括每一个项目在执行更新操作时版本库中的版本。
如果你在进行更新后再撤销更改，工作副本将返回到版本库的状态，而不是你开始进行更改前的状态。
本地删除，当更新时有更改进入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被标记为添加(包括其历史记录)并且产生树冲突。