SVN 树冲突和目录丢失问题（1）
临下班了，一个老朋友（之后用yzw代称）在MSN 上呼我。说他的SVN 遇到问题了：
?在执行分支合并时，一个目录发生了树冲突
?直接在硬盘上将该目录删除
?之后执行svn update 该目录不能检出
?不知道树冲突为何物，也不知道目录怎么变成了一团糟
好吧，谁让他公司的SVN 是我给部署的呢？让他（yzw）执行svn status 命令，看看显示什么信息，然后我在本地建立一个模型，争取重现并解决他的问题。
在已经一团糟的目录下，执行svn 显示的信息如下：
看来他遇到的树冲突，是因为在两个分支同时创建了一个同名目录somedir，然后在合并更新时出现树冲突。
重现问题的过程
版本库准备
1.创建svn 版本库于/tmp/svnserver
2.检出版本库到目录~/tmp/svntf 下（windows用户需要知道的是：~ 代表我的主目录
/home/jiangxin 是也）
3.创建SVN 三个顶级目录：trunk tags branches
4.创建分支branches/0.x
5.在branches/0.x 分支下创建目录somedir，并增加一个文件somedir/branch.txt
6.在主线trunk 下也创建一个目录somedir，并增加一个文件somedir/trunk.txt
看看目前的版本情况
备份当前的 .svn 目录
直接拷贝 .svn 到 .svn-orignal，以便在出现意外的时候，进行参照。
“.svn*”。（问题优点复杂化了，算了）
合并分支改动，引发异常
o而我的结果是：
o看来，还需要作些工作才能完全重现错误。
15.这时我又备份了一下 .svn 目录，将 .svn 复制到 .svn-merge-conflict，以便后面比较
实际上，通过比较 .svn 目录和之前备份的 .svn-merge-conflict 可以看出端倪：
执行svn status，看到本地工作目录的冲突状态已经消失了，一切看起来正常了。
但是，慢着，此时somedir 目录没有了！
实际上，这时版本库中还有somedir 目录，我们可以用svn ls 命令查看：
但是本地的确已经没有了。如果要刨根问底的话，可以比较一下 .svn 目录和我们之前创建的备份：
居然没有发生冲突。yzw 这时后一定很欣喜，居然可以成功合并了。
再看看状态？
SVN 树冲突和目录丢失问题（2）
前面的博文《SVN 树冲突和目录丢失问题（1）》，介绍了重现update 导致树冲突的重现过程。那么应该如何解决树冲突，以及如何找回丢失目录呢？首先我们需要了解：
什么是树冲突？
首先关于树冲突的概念，最好的参考是：SVN BOOK的有关树冲突的章节。
?平时我们说的冲突，是因为对同一文件的不同修改造成的冲突。
?树冲突，指的是由于目录（文件）树的改变，造成内容修改修改不能匹配在同一对象（目录/文件）上
?例如：由于在一个分支中修改的目录和文件，在另外的分支出现了改名的操作。
?或者像yzw 的例子，因为两个分支同时增加了一个同名的目录，导致了树冲突。
树冲突的解决，首先要说的是要最好使用svn 1.6 的客户端。因为svn 1.5 的客户端对树冲突的处理不好，甚至根本发现不了树冲突，很容易忽略潜在的冲突，出现意想不到的结果。
SVN BOOK 中举了一个本地修改，远程重命名的例子。
例如svn 1.5 处理这种本地修改/远程文件改名的情况，可能会出现如下结果：
?发现远程改名，则检查本地文件是否包含修改，若不包含修改直接删除。
?结果因为远程改名的文件，本地包含修改，因此不删除，而是保留该文件，但是文件的状态变为未受版本控制状态。
?本地会显示一个新增文件，实际上是本地修改文件的原始（修改前）版本重命名后的文件。
?这时，如果不太细心（谁那有那么细心？），就会丢失本地的改动。
对于svn 1.5 最困难的是发现冲突，当然解决冲突也要靠手工比较完成：将本地文件改动在重命名后文件中再次改动一次！
对于svn1.6 来说，引入了树冲突的概念，看似复杂度增加了，实际上是解决了两个问题：
?识别冲突的问题：
将本地修改的文件标记为树冲突
?改动合并的问题：
将本地修改合并到远程改名后的文件中。因为远程改名后的文件来自于本地修改的原始文件
当然对于远程重命名的例子，还要你最终的决定权还是在于你自己：
?是否接受远程的文件重命名操作？
?你需要手动将树冲突的状态予以解决：本地文件删除即接受远程重命名；
?或者将远程添加的文件删除即不允许重命名。
?对于前一种状况（即接受远程重命名），本地改动SVN 1. 6的客户端已经自动合并到远程改名后的文件中了。
那么对于yzw 的情况呢？
本地和远程同时添加目录？
yzw 遇到的树冲突，是因为本地和远程同时添加了相同的目录。实际上，我们在上一个博客中已经看到了两种不同的解决方案影子：
?本地添加somedir 目录并提交后，执行合并，显示：“合并引发的树冲突”
o这时，如果执行svn resolve –accept working somedir 命令解决冲突的话，
o就相当于说：“采用我增加的somedir 目录，他增加的somedir 目录不算数”
o然后提交即可
?树冲突发生后：
o还原冲突
o删除主线中的目录。潜台词是：我本地的修改不要了，而是使用远程（分支）添加的目录
o然后再执行从分支到主线的合并操作
o合并成功，提交。
o也就是说，采用的策略是：“采用他增加的somedir 目录，我增加的somedir 目录不算数”
看看实际操作的例子：
接受我的修改，远程的修改不算数
?使用svn resolve –accept working 解决冲突：
~/tmp/svntf/trunk$ svn resolve –accept working somedir
“somedir”的冲突状态已解决
~/tmp/svntf/trunk$ svn st
M .
? .svn-merge-conflict
? .svn-update-conflict
? .svn-orignal
接受远程的修改，我的修改不算数
上一个博文中，我几经尝试，进入到了由于更新引发的树冲突。但是在上一个博客示例最后的更新引发树冲突的状态，虽然也可以用svn resolve 命令解决树冲突，但是无法提交。
总是报错
无论你如何执行svn update，解决过时错误，也仍然不能提交。会陷入一个无穷无尽的冲突解决==>过时冲突的循环中。
一个撤销本地修改，接受远程分支修订的解决的办法是：
出来。如果先执行–set-depth 为其他，在执行–set-depth infinity 倒是能够找回somedir。但
是这个方法太过奇怪，好像是SVN 的一个BUG，通过奇怪的操作绕过去了一样。我用下面的命令找回丢失的somedir 目录：
中间出现了一次过时问题，是因为目录属性修改，而目录的版本号尚未更新。这其实是svn 混杂版本号造成的，已经超出本博文的内容。
总结
好了，通过这个例子，我介绍了增加同名目录引发的树冲突的解决方案。
?如何保留本地修改，取消远程修改
?如何取消本地修改，保留远程修改
?怎样的操作，会使svn 进入一个无法解决的冲突合并状态，以及如何解决
?发现了一个SVN 本地目录丢失无法通过svn update 找回的问题，以及两种解决方法：o一个很古怪：分别使用不同的–set-depth 值执行多次update，不过最终会成功
o另外一个却需要知道丢失的目录名称，如果不知道本地有哪个目录缺失，就很难操作了最后，要向老杨的致谢，是他间接的为我们网站增加了两个博客。
老杨是我见过的最牛的程序员，但是他的CVS 的死忠和对SVN 的憎恨让我觉得异常诧异。可能他和Linus Torvalds 很想像，但又有不同，因为Linus 对CVS 和SVN 同样憎恨。
我估计老杨一旦有时间（刚刚结婚，可能很难有时间），一旦掌握了Git，他就会把CVS （还有SVN？）扔到九霄云外。不过我估计他还得需要SVN 和GIT 接合使用，因为毕竟他现在做的是商业软件开发，还需要精细的代码授权（至少是对别人授权）。
后记：
睡醒一觉后，发现俺的闺女小雪已经学会了one, two, three, four！真的不是吹的，2岁5个月的小孩，千字文已经可以从“天地玄黄背”到“如松之胜”，上个月开始莫名的喜欢英文歌，今天早晨居然会说one, two, three, four! “姑娘，别累坏了，不过要是你喜欢，…”
欣喜之余，想到给yzw 的博文莫不如扩充到one, two, three, four。于是就有了下面两个博文：
?《SVN 树冲突和目录丢失问题（3）》
一个更加简单重现yzw 问题的方法
?《SVN 树冲突和目录丢失问题（4）》
一个更有意义和技术含量的冲突解决办法，可以让合并的双方不是“你死我活”的争斗，而是“谐和”SVN 树冲突和目录丢失问题（3）
昨天在《SVN 树冲突和目录丢失问题（1）》中重现yzw遇到的“更新导致树冲突”，实际上可以有更简单的重现方法。
大概的方法是：
?将主线trunk 更新到老的版本，该老的版本尚不包含somedir 的提交
?然后从branches/0.x 分支合并到主线
?提交会引发过时错误
?执行svn 更新
?更新引发树冲突
具体的操作是：
1.查看当前主线的log
38.执行svn 更新，引发树冲突
43.查看树冲突的状态
解决目录重名的树冲突，可以参照“SVN 树冲突导致和目录丢失问题（2）”中介绍的方法。
?采用分支的修改，抛弃本地（主线）的修改
本地还原到trunk 最新提交==> 删除somedir 目录==> 提交==> 执行更新以免由于目录属性修改导致过时错误==> 将分支0.x 合并到主线==> 合并成功，没有冲突==> 提交合并结果到主线
?采用本地（主线的修改），抛弃分支的修改
还原到trunk 最新提交==> 将分支0.x 合并到主线==> 引发合并导致的树冲突==> 用svn resolve –accept working 标记somedir 的树冲突已经解决==> 提交合并结果到主线
可是在实际的情况下，上面的两个方法还是不够的，这就需要在对SVN合并机制充分理解的基础上，用一点小巧门。我们下篇文章介绍一个更加具有现实意义的合并方法。
SVN 树冲突和目录丢失问题（4）
前面《SVN 树冲突和目录丢失问题（2）》中介绍的冲突解决机制，是“你死我活”（vice versa）式的冲突合并，在实际环境中，可能会有“你中有我，我中有你”式的合并。
?主线和分支的同名目录中的内容都需要保留
?分支中同名的目录包含多次提交，需要合并后保留分支的提交历史
如果你确实有这种需要，那么看过来。
关于svn:mergeinfo 属性
首先，我们需要知道svn 1.5 版本增加的svn:mergeinfo 属性。
?在SVN1.5 版本之前，SVN 的合并操作不会比CVS 强多少，这也是很多有识之士痛贬SVN 的原因
?SVN 痛定思痛，终于在1.5 版本设计出来svn:mergeinfo 属性。这多亏了SVN 的目录和文件属性的强大功能
?svn:mergeinfo 属性取代了程序员自己手工维护的合并记录单。
?就是说，之前为了避免重复合并，程序员往往需要将每一次合并的操作记录在一个本本中。CVSer 都是这么做的，对么yzw？
?svn 1.5 会把合并结果记录在目录的svn:mergeinfo 属性中，这样在合并的时候，可以不必再提供合并的版本范围，SVN会帮助你跳过已经完成合并的版本
警告：对于一个公司来说，为了避免由于低于 1.5 版本的SVN 客户端合并时破坏svn:mergeinfo 机制，应该配置SVN 的钩子，禁止低于1.5 版本的SVN 客户端访问。
一个更加现实的例子
分析和设计合并路线
现在的合并需求是：
?将分支中增加的somedir 目录合并到主线的somedir 目录中
?在合并后的主线中，保留分支0.x 的r5 和r6 的提交历史
可能会发生树冲突的是：
?分支0.x 的r3 版本增加了目录somedir
?主线的r4 版本也增加了目录somedir
?所以r3 和r4 会造成树冲突
不合并仅标记合并，即手工标记合并成功
所谓标记合并，就是说我们不真正合并，而只是在svn:mergeinfo 中进行标记：“我已经合并了分支0.x 的版本3”。你当然可以直接用svn propset 命令设置svn:mergeinfo 属性，但是我还是建议你使用svn merge 命令，不过要带一个–record-only参数。
该参数（–record-only），在乌龟SVN中的图形界面中叫做“仅标识”，就是说不执行merge 操作，而是在svn:mergeinfo 中标记上已经合并了相应的提交。
那么我们为主线标记上：已合并了分支的提交3
操作如下：
手工完成r3 到主线r4 的内容合并
分支0.x 的r3增加了一个新文件，复制到主线的somedir 目录中，我们就完成了r3 和r4 的内容合
执行分支到主线合并操作，将分支历史带入主线
看看合并后的历史
参数“-v ” 可以查看提交的文件统计信息；参数“-g” 可以查看合并源的日志信息
解决版本冲突－使用SVN主干与分支功能 1前言 大多数产品开发存在这样一个生命周期：编码、测试、发布，然后不断重复。通常是这样的开发步骤： 1) 开发人员开发完毕某一版本（如版本A）功能后，提交测试； 2) 测试人员对待发布版本A进行测试，同时开发人员继续开发新功能(如版本B)； 3) 测试人员提交bug，研发人员修复bug，同时继续开发新功能； 4) 重复第3步骤，直到待发布版本A测试通过测试后，发布第一版本 这样就会存在以下问题： 1) 如何从代码库中(A+B)分离出待发布版本A，进行测试和发布； 2) 如果单独存放待发布版本A，那么开发组必须同时维护此版本库A以及当前最新代码库 (A+B)，操作冗余且容易出错。 在SVN中，通常采用主干（trunk）与分支（branches）的方法，解决以上问题。 2相关概念和原理 在SVN中创建代码库时，通常会创建trunk、branches、tags三个子目录，当然，你也可以用其他名称来实现主干和分支的功能 trunk－主干，或称主线，顾名思义，是开发的主线。 branches－分支，是从主线上分出来，独立于主线的另一条线。可以创建多个分支。一个分支 总是从主干一个备份开始的，从那里开始，发展自己独有的历史(如下图所示)。在版本控制的 系统中，我们经常需要对开发周期中的单独生命线作单独的修改，这条单独的开发生命线就可 以称为Branches，即分支。分支经常用于添加新的功能以及产品发布后的bug修复等，这样 可以不影响主要的产品开发线以及避免编译错误等。当我们添加的新功能完成后可以将其合并 到主干中。 tags－标记，主要用于项目开发中的里程碑，比如开发到一定阶段可以单独一个版本作为发布 等，它往往代表一个可以固定的完整的版本。即主干和分支都是用来进行开发，而标记是用来 进行阶段发布的。安全公司的配置库有专门的发布区，所以tags并不需要创建，在这里只是 提供说明，不推荐使用。 branches以及tags在TortoiseSVN中创建方法是一致的，它们都是通过存储类似Linux中的lunch 快捷方式一样，只是创建了指向某个版本的链接，而不会真正将此版本的内容复制到分支或者标记中，这样既可以节省空间，也可以很快速的创建，被称为“廉价的拷贝”。 为了便于创建分支和标记，通常习惯于将Repository版本库的结构布置为:/branches,/tags,/trunk。 分别代表分支，标记以及主干。
解决代码冲突 如果commit时出现“You have to update your work copy first.”红色警告，说明版本库中的此文件已经被其他人修改了。请先点“ok”按钮退出。执行update,然后再commit。 如果修改与update得到的代码不冲突，则自动合并。如果冲突（比如对同一行代码进行了修改），则出现”One or more files are in a conflicted state.“红色警告，并产生几个文件记录冲突。一般情况下，我们不要直接编辑冲突文件。而按照以下操作手工解决冲突。 在资源管理器中，选择commit时冲突的那个文件，鼠标右键菜单选择”Edit conficts”。 出现界面，分为”Theirs”、”Mine”和”Merged”3部分，表示”别人修改的内容”、”我修改的内容”和”合并后的结果”3部分。我们是要将”别人修改的内容”和”我修改的内容”有取舍地合并起来，形成”合并后的结果”。 合并一般分为4种情况： 保留”我的修改”,舍弃”别人的修改”。鼠标右键点击Mine框的相应行，点击”Use this text block”。 舍弃”我的修改”,保留”别人的修改”。鼠标右键点击Theirs框的相应行，点击”Use this text block”。 同时保留”我的修改”和”别人的修改”，并将”我的修改”放在前面。鼠标右键点击Mine 框的相应行，点击”Use text block from mine before theirs”。 同时保留”我的修改”和”别人的修改”，并将”别人的修改”放在前面。鼠标右键点击Mine框的相应行，点击”Use text block from theirs before mine”。 合并完成，Ctrl+S存盘，退出。 然后，在资源管理器中，选择冲突文件，鼠标右键菜单选择”Resolved”,标记冲突已解决。系统会自动删除因冲突而新建的文件。此时，就可以继续进行commit操作了。 本文来自CSDN博客，转载请标明出处：https://www.doczj.com/doc/6d2546423.html,/gori/archive/2009/04/12/4067588.aspx
第1节背景及svn简介 svn是subversion 缩写，它是一个自由、开放源码、多用户的版本控制系统, 支持通过本地或远程访问数据库和文件系统存储库。Subversion 管理着随时间改变的数据。这些数据放置在一个中央资料档案库(repository) 中。这个档案库很像一个普通的文件服务器，不过它会记住每一次文件的变动。这样你就可以把档案恢复到旧的版本，或是浏览文件的变动历史。许多人会把版本控制系統想像成某种“时光机器”。 版本控制是管理数据变更的一种技术。对于程序员来说，它已经成为不可或缺的工具，因为他们经常修改软件代码，产生部分的变更，然后第二天再取消所有的变更。想象有一群程序员同时工作的情况你就能理解，为什么需要一个良好的系统来管理可能出现的混乱。 SVN 不但提供了常见的比较、合并、标记、提交和分支功能，SVN 还增加了追踪移动和删除的能力。此外，它还支持非ASC Ⅱ文本和二进制数据、原子性提交、HTTP 访问等特性，当SVN 被广泛使用时，也需要有个管理工具能够更方便安全地维护SVN 的用户、组、权限、库等内容，协助普通用户更好地配置管理SVN，而无需都交由可能比较繁忙的系统管理员维护。而基于Web 的Subversion 管理工具将是一种非常适合的选择。SVN 可以支持windows 和Linux 两种操作系统，在两种操作系统上运行都具有稳定性和安全性。
SVN 在设计上包括了一个抽象的网络层，这意味着SVN 的版本库可以通过各种服务器进行访问，而允许程序员为客户端“版本库访问”的API 写出先关协议的插件，理论上讲，SVN 可以使用无限数量的网络协议，目前提供了有两种服务器运行方式：一种是Subversion Standalone Server。即svnserve，一个小型的独立服务器，另一种是基于Apache Http Server，即Web 服务器，它通过mod_dav_svn 模块，客户端使用WebDAV/DeltaV 协议进行访问。 SVN站在更高层次上对现在的安全产品，从系统和控制的角度进行了"有机"和"无隙"的整合。 SVN是一个安全虚拟网络系统，它将系统整体的信息安全功能均衡合理地分布在不同的子系统中，使各子系统的功能得到最大限度的发挥，子系统之间互相补充，系统整体性能大于各子系统功能之和，用均衡互补的原则解决了"木桶原理"的问题。 SVN能在跨接Internet, Intranet, Extranet间的网络所有端点实现全面的安全，而且还能提供基于企业策略的信息管理机制以充分有效地利用有限的带宽。SVN可以满足各种企业VPN的要求，通过为公司内部网络、远程和移动用户、分支机构和合作伙伴提供基于Internet的安全连接。所以，我们可以将SVN看成是VPN、防火墙、基于企业策略的信息管理软件集成在一起的Internet安全的综合解决方案。在这样一个网络系统中，所有互联网服务器端和客户端都是安全的，并有一个信息管理机制以不断地通过这个外部网络环境动态地分析及满足客户的
开发者在开发一个项目的时候，一般都是一个团队开发协作。那么对于代码管理这一块就要用到SVN了。下面就给大家介绍一下在AppCan IDE 3.0中建立项目需要用到SVN管理的一系列流程。 1、SVN安装 1.下载svn软件：TortoiseSVN SVN软件分32-bit和64-bit运行环境，用户可依照自己的操作系统，下载相应的软件版本。这里以中文版举例。 2.下载完成之后，安装TortoiseSVN。正确安装之后，重启系统。 3.安装成功后，右键单击鼠标，应该可以看到如下图所示：
2、AppCan项目开发使用SVN流程 AppCan IDE 3.0开发版需要用户在https://www.doczj.com/doc/6d2546423.html,网站上注册用户名和密码，建立自己的帐号，才能够创建项目，具体创建项目流程请参考IDE开发流程文档。 创建一个项目后，AppCan会自动给用户生成一个唯一的ID和KEY值。 开发者可在本地建目录存放项目文件，通过SVN进行管理。 SVN管理流程举例说明如下： 1.在D盘下建立一个AppCansss的文件目录；。 2.右键点击文件夹，如图所示： 选择“SVN检出”，如图所示：
在版本库URL处输入在AppCan官网上创建项目时获得的上传地址（这里的上传地址就是用户的SVN管理地址），检出至目录默认是当前目录，点击“确定”，弹出提示，输入用户名和密码。用户名和密码由用户在AppCan官网注册获得。 点击“确定”，将相关项目文件保存在本地目录，如图所示：+
在AppCan IDE 3.0中新建项目，输入相应的应用ID和应用KEY。创建成功之后。会看到默认生成有一个android_iphone的文件夹。建立页面文件之后，整个项目如图所示： 在D盘建立的AppCansss文件下新建ceshi111文件，把创建的项目放在此文件夹下，把项目代码添加到SVN上。
SVN环境搭建及使用手册 一、SVN介绍 SVN是Subversion的简称，是一个开放源代码的版本控制系统，相较于RCS、CVS，它采用了分支管理系统，说得简单一点SVN就是用于多个人共同开发同一个项目，共用资源的目的。 二、SVN安装包介绍（安装包存放在服务器上D:\安装包\SVN） 服务端：SVN服务端安装包是VisualSVN-Server-3.6.0-x64.msi。 客户端：客户端软件主要包括下列3个文件 1. TortoiseSVN-1.8.8.25755-x64-svn-1.8.10.msi ----SVN客户端安装包 2. LanguagePack_1.9.5.27581-x64-zh_CN.msi ----SVN客户端语言包 3. AnkhSvn-2.5.12471.17.msi -----SVN针对Visual Studio的插件 三、搭建SVN服务端详细说明 第一步：搭建SVN团队项目、在服务器上打开已安装的SVN服务端、新建一个项目文件夹、创建完成后、右键项目复制项目URL 具体如下图
第二步：创建SVN用户、及设置密码、如下图 第三步：SVN服务端创建项目完成及创建用户后、使用SVN客户端将程序代码等文件提交上去、选中需要提交的程序文件、并填写正确SVN服务端项目的URL地址、
四、在日常开发中使用SVN的常用操作主要有：签出程序、文件合并、代码文件撤销、版本回滚、及历史版本控制等 说明：使用SVN版本控制，必须遵循4个原则。 1.新建文件前获取最新的程序代码、新建文件后先提交文件、再进行详细开发或编辑。 2.尽量避免多人同时处理同一个文件（svn毕竟不是那么优秀、无法智能将代码成功合并）。 3.项目成员提交程序前、必须获取最新的程序、编译且没问题、再进行提交操作。 4.提交代码必须选择解决方案进行代码提交、请勿选择其中某项目进行提交。 （1）签出最新程序：选择解决方案右键--》Update Solution to Latest Version, 如下图 （2）代码文件合并：如svn上的文件与本地文件产生冲突、则会在Pending Changes 中高亮显示、双击文件打开双方文件差异、合并完成后、点击Commit进行合并后文件提交。如下图
SVN解决版本冲突功能 1代码的分支管理策略 关于代码管理的分支和发布策略，目前主要有两种：一种是主干作为新功能开发主线，分支用作发布。另一种是分支用作新功能开发，主干作为稳定版的发布。 1.1分支用来发布 典型操作步骤如下： 1) 开发者提交所有的新特性到主干。每日的修改提交到/trunk：新特性，bug修正和其他。 2) 这个主干被拷贝到“待发布”分支。当小组认为软件已经做好发布的准备（如，版本1.0） 然后/trunk会被拷贝到/branches/1.0。 3) 项目组继续并行工作，一个小组开始对分支进行严酷的测试，同时另一个小组在/trunk继续 新的工作（如，准备2.0），如果一个bug在任何一个位置被发现，错误修正需要来回运送。 然而这个过程有时候也会结束，例如分支已经为发布前的最终测试“停滞”了。 4) 分支已经作了标记并且发布，当测试结束，/branches/1.0作为引用快照已经拷贝到/tags/1.0.0， 这个标记被打包发布给客户。 5) 分支多次维护。当继续在/trunk上为版本2.0工作，bug修正继续从/trunk运送到/branches/1.0， 如果积累了足够的bug修正，管理部门决定发布1.0.1版本：拷贝/branches/1.0到/tags/1.0.1， 标记被打包发布。 整个过程随着软件的成熟不断重复：当2.0完成，一个新的2.0分支被创建，测试、打标记和最终发布，经过许多年，版本库结束了许多版本发布，进入了“维护”模式，许多标记代表了最终的发布版本。 这种分支管理策略被广泛的应用于开源项目。比如freebsd的发布就是一个典型的例子。 freebsd的主干永远是current，也就是包括所有最新特性的不稳定版本。然后随着新特性的逐步稳定，达到一个发布的里程碑以后，从主干分出来一个stable分支。freebsd是每个大版本一个分支。也就是说4.x，5.x，6,x各一个分支。每个发布分支上只有bug修改和现有功能的完善，而不会再增加新特性。新特性会继续在主干上开发。当稳定分支上发生的修改积累到一定程度以后，就会有一次发布。发布的时候会在稳定分支上再分出来一个 release分支。以 6.x为例，就会有 6.0,6.1,6.2…等发布分支。 这种发布方法非常适用于产品线的发布管理。产品是要卖的，以前卖给客户的版本仍需要继续维护，而为了以后的市场，新功能也不断地在增加。这种管理方法对已发布产品的维护工作和下一代产品的开发工作进行了隔离。对于已经发布的产品，只有维护的补丁发布。而新发行的产品不仅包括了所有的bug修改，还包括了新功能。 这种方法具有如下缺点：首先，必须对主干上的新功能增加进行控制。只能增加下一个发布里面计划集成进去的新特性。而且，已经在主干上集成的新特性中的任何一个，如果达不到里程碑的要求，稳定分支就不能创建，这很有可能影响下一个发布的计划。开源项目可能这方面的压力小一些，但是商业产品开发如果碰到这种情况就危险了。还有一个缺点就是bug修改必须在各个分支之间合并。 从分支和合并的一些实践经验上看，各个长期存在的分支之间必须要周期性的进行合并，否则很容易引发合并冲突。可是各个stable分支以及release分支之间恰好是不能进行合并而且还要长期存在的。因此，采用这种分支策略可能碰到的最大问题就是某个分支上的bug修改内容往其它分支merge 的时候出现的冲突。而且一旦发现一个bug，调查这个bug影响哪些分支的工作会随着维护的发布分支的数量而增加。
TECHNOLOGY TREND ［摘要］在中小规模软件项目的开发过程中，通常由多人分工、共同完成，这就涉及到大量的源代码和文档。即使在沟通充分情况下，多 人维护同一份源代码也会出现混乱情况，如何对这些源代码和文档进行有效版本管理，并进行最终整合，是软件项目能否成功的关键之一。［关键词］版本控制；SVN VisualSVN ；Server ；TortoiseSVN 利用SVN 对软件项目进行版本控制管理 闫晗 （天津港信息技术发展有限公司，天津市 300000） 在中小规模软件项目的开发过程中，通常由多人分工、共同完成，这就涉及到大量的源代码和文档。即使在沟通充分的情况下，多人维护同一份源代码也会出现混乱的情况，如何对这些源代码和文档进行有效的版本管理，并进行最终整合，是软件项目能否成功的关键之一！本文简要介绍一套Windows 操作系统下利用免费、开源软件构建的高效、可靠的SVN 版本管理系统及其日常备份方法。 1SVN 简介SVN （Subversion ）是一种版本管理系统，其前身是CVS （Con-currentVersions System ），它是根据CVS 的功能为基础来设计的，它除包括了CVS 的大多数特点外，还有一些新的功能：文件目录可以方便的改名、基于数据库的版本库、操作速度提升、权限管理更完善等。 SVN 通过对不同项目建立各自独立的版本库进行管理，每个版本库很像一个基于数据库的文件服务器，可以记录每一次文件和目录的修改内容，这使得用户可以取得文件以前的版本，检查所做的任何更改。SVN 采用HTTP 方式访问版本库，从而使用户可以在不同的电脑上获得（CheckOut ）项目文件，经修改后再提交（Import ）到SVN 服务器。另外，SVN 允许多个用户对同一份文件进行修改，当提交（Im-port ）到SVN 服务器时会自动对该文件的不同用户版本进行融合（Merge ）。当融合过程中有冲突（Conflict ）发生时，SVN 会给出提示信息，用户可以借助SVN 的文档比较功能来解决冲突。 借助SVN 的版本管理，所有开发人员的项目文件都可被同步更新，因而开发工作可能变得非常顺利。文章所介绍的SVN 版本管理系统主要用到VisualSVN Server 和TortoiseSVN 这两个软件，VisualSVN Server 是一款图形化的SVN 服务器软件，提供Subversion 、Apache 服务器（提供HTTP 服务）和用户及权限管理等功能；TortoiseSVN 作为一款SVN 客户端软件，通过将功能项目嵌入到资源管理器的右键菜单，并借助其强大的图形化操作方式为用户提供方便快捷的SVN 服务。读者可以在https://www.doczj.com/doc/6d2546423.html, 和https://www.doczj.com/doc/6d2546423.html,/免费下载到这两个软件的最新版本。 2SVN 系统配置和使用2.1服务器端 在服务器安装端VisualSVN Server 的过程中，需要填写一个HTTP 服务端口号，如要采用安全连接，可勾选“Use secure connec-tion(https://)”选项，其他部分采用默认设置即可。 VisualSVN Server 中主要包括版本库（Repositories ）、用户（ Users ）和组（Groups ）三部分，通过各自上下文菜单可以新建版本库、用户和组。通过版本库的上下文菜单“Properties ”可以设置其访问用户和权限，同时其HTTP 访问地址也可通过右键菜单“CopyUrlto Clipboard ”拷贝至剪贴板，例如：http://192.168.0.55:8888/svn/a-jsys/。至此，一个新版本库建立完成，非常高效、便捷！ 2.2客户端 安装过程无需太多配置，安装完成并需要重新启动后，资源管理器的右键菜单会增加多个TortoiseSVN 项目。 接下来向SVN 服务器中导入项目，项目结构可以按照“项目源码”、“项目文档”等进行分类以方便管理。在项目文件夹上点击右键并选择“Import ”菜单，在弹出的对话框中的“URLofrepository ”中填入刚才拷贝的URL 地址并点击OK ，在填入用户名和密码后，即可开始将项目导入SVN 服务器。 在导入完成后，还需要对刚才导入的项目通过右键上下文菜单“SVNCheckout ”检出，以后在该文件夹中对文件所进行的新增、修改、删除等操作都将被SVN 记录。 被纳入SVN 管理的文件夹和文件图标会根据不同状态发生改变，常见的有：“绿色√”表示没有被本地修改过；“红色！”表示被本地修改过；“黄色！”表示和服务器上版本存在冲突且无法自动融合；“蓝色？”表示该文件或文件夹为新增，不受版本控制，可以在提交对话框中选择是否提交到SVN 服务器。 在检出后的项目文件夹上点击右键，我们会发现新增了许多Tor-toiseSVN 菜单项，下面对常用的几个菜单进行介绍： SVNUpdate-更新，使本地项目文件与SVN 服务器进行同步。 SVNCommit-提交，提交本地修改后的项目文件至SVN 服务器，以便其他项目成员进行同步更新。 Revert-还原，可以将指定文件或文件夹还原至服务器最新版本。Show Diff-显示不同，该功能十分有用，主要用于本地版本与服务器版本存在冲突时进行对比。 通过以上的简单操作，我们已经构建起一套完整的SVN 版本控制系统，完全可以胜任中小规模软件开发的版本控制管理。SVN 服务器中存储着各个项目的版本库数据，因此也要做好这些数据的日常备份。 3SVN 服务器备份 VisualSVNServer 在数据备份方面提供了一条svnadmin 命令，借助批处理程序并结合Windows 系统的“任务计划”功能对版本库数据进行备份。 备份过程主要涉及到2个文件：backup.bat 和backupcmd.bat 1）backup.bat 文件作为主程序，其主要内容为：@echooff setSVN_HOME="C:\Program Files\VisualSVNServer"setSVN_ROOT=E:\Repositories setBACKUP_SVN_ROOT=E:\svnrootbak setBACKUP_DIRECTORY=%BACKUP_SVN_ROOT %\%date ~0,10%、 ifexist%BACKUP_DIRECTORY %gotocheck mkdir%BACKUP_DIRECTORY % for/r%SVN_ROOT %%%Iin(.)do@ifexist"%%I\conf\svnserve conf"call%BACKUP_SVN_ROOT %\backupcmd.bat"%%~fI"%%~nI end 2）backupcmd.bat 文件作为副程序被backup.bat 调用，其内容 为： @%SVN_HOME%\bin\svnadmin hotcopy%1%BACKUP_DI-RECTORY %\%2 本例中，在SVN 服务器分区E 下建立文件夹svnrootbak ，并将上 述三个文件拷贝至该文件夹下，通过Windows 的任务计划功能设定在每天特定时间执行backup.bat ，即可实现无人职守的版本库备份。 在中小规模软件项目的开发过程中，为了进行有效的协同开发而进行版本控制是一个基本要求。近两年，基于开源的SVN 构建的版本控制系统逐渐成为对软件项目开发进行版本控制的首选。但版本控制不只局限于软件开发领域，在档案管理、信息管理等领域也可得到应用。 应用科技 59
SVN冲突解决方法大全 2010-05-27 09:33 佚名我要评论(0)字号：T | T 本文和大家一起来学习SVN冲突解决和winmerge使用手册，本文介绍了几个SVN冲突解决的方法，希望大家通过本文的学习能够掌握，欢迎大家一起来学习。 AD： 本节向大家介绍一下SVN冲突解决和winmerge使用手册问题，在学习SVN的过程中，难免会遇到SVN冲突问题，于是和大家分享一下，看完本文你肯定有不少收获，希望本文能教会你更多东西。 解决版本冲突的命令。在冲突解决之后，需要使用svnresolved来告诉subversion冲突解决，这样才能提交更新。冲突发生时，subversion会在WorkCopy中保存所有的目标文件版本（上次更新版本、当前获取的版本，即别人提交的版本、自己更新的版本、目标文件。假设文件名是sandwich.txt，对应的文件名分别是：sandwich.txt.r1、sandwich.txt.r2、sandwich.txt.mine、sandwich.txt）。同时在目标文件中标记来自不同用户的更改。 解决SVN冲突的办法： -手动解决：冲突发生时，通过和其他用户沟通之后，手动更新目标文件。然后执行svnresolvedfilename 来解除冲突，最后提交。 -放弃自己的更新，使用别人的更新。使用最新获取的版本覆盖目标文件，执行svnresolvedfilename并提交。 -放弃自己的更新，使用svnrevert，然后提交。在这种方式下不需要使用svnresolved。 对于svnresolved命令需要非常小心，必须是非常确定冲突已经解决才能使用。否则，会导致Subversion 以为冲突解决，而使代码库不正确。 解决冲突详细文 档:https://www.doczj.com/doc/6d2546423.html,/1.2/svn.tour.cycle.html#svn.tour.cycle.resolve 解决冲突（合并别人的修改） 我们可以使用svnstatus-u来预测冲突，当你运行svnupdate一些有趣的事情发生了： $svnupdate UINSTALL GREADME Cbar.c Updatedtorevision46. U和G没必要关心，文件干净的接受了版本库的变化，文件标示为U表明本地没有修改，文件已经根据版
版本冲突原因： 假设A、B两个用户都在版本号为100的时候，更新了kingtuns.txt这个文件，A用户在修改完成之后提交kingtuns.txt到服务器，这个时候提交成功，这个时候kingtuns.txt文件的版本号已经变成101了。同时B用户在版本号为100的kingtuns.txt文件上作修改，修改完成之后提交到服务器时，由于不是在当前最新的101版本上作的修改，所以导致提交失败。 版本冲突现象： 冲突发生时，subversion会在当前工作目录中保存所有的目标文件版本[上次更新版本、当前获取的版本(即别人提交的版本)、自己更新的版本、目标文件]。 假设文件名是kingtuns.txt 对应的文件名分别是： kingtuns.txt.r101 kingtuns.txt.r102 kingtuns.txt.mine kingtuns.txt。同时在目标文件中标记来自不同用户的更改。 版本冲突解决： 场景： 1、现在A、B两个用户都更新kingtuns.txt文件到本地。
2、文档中原始文件内容如下： 3、A用户修改文件，添加内容“A用户修改内容”完成后提交到服务器
4、B用户修改文件，添加内容“B用户修改内容”完成后提交到服务器
B用户提交更新至服务器时提示如下： B用户将文件提交至服务器时，提示版本过期：首先应该从版本库更新版本，然后去解决冲突，冲突解决后要执行svn resolved（解决），然后在签入到版本库。在冲突解决之后，需要使用svn resolved（解决）来告诉subversion冲突解决，这样才能提交更新。 解决冲突有三种选择： A、放弃自己的更新，使用svn revert（回滚），然后提交。在这种方式下不需要使用svn resolved （解决） B、放弃自己的更新，使用别人的更新。使用最新获取的版本覆盖目标文件，执行resolved filename并提交(选择文件—右键—解决)。 C、手动解决：冲突发生时，通过和其他用户沟通之后，手动更新目标文件。然后执行resolved
针对原文做了两个修改，见文中【修改】部分，不然不能正确配置服务器，并且添加了一些注释（flywen 2010-9-28） 原文出处： https://www.doczj.com/doc/6d2546423.html,/ttzhang/archive/2008/11/03/1325102.html https://www.doczj.com/doc/6d2546423.html,/ttzhang/archive/2008/11/04/1325940.html 文章版权归原作者Forrest Zhang所有。 一、VisualSVN Server的配置和使用方法【服务器端】 1.1 VisualSVN Server的安装 最新版本是1.6.1，你可以在这里下载： https://www.doczj.com/doc/6d2546423.html,/files/VisualSVN-Server-1.6.1.msi VisualSVN Server，最新更新版本是1.6.2，你可以在这里下载： https://www.doczj.com/doc/6d2546423.html,/files/VisualSVN-Server-1.6.2.msi VisualSVN Server Documentation下载： https://www.doczj.com/doc/6d2546423.html,/server/doc/VisualSVN-Server.pdf 下载后，运行VisualSVN-Serv er-1.6.1.msi程序，点击Next，下面的截图顺序即为安装步骤： 图1：
图2： 注意：Server Port那里，默认端口有80/81/8080三个；如果最后面的CheckBox被选中，则表示使用安全连接【https协议】，这是的端口只有433/8433二个可用。Location 是服务器端的安装位置，Repositories是代码仓库，这里保留一份总的代码，别人的需要从中check out代码，修改后再commit回这个仓库 图3：
版本控制系统（集中模式） (1) 版本控制系统指南 (5) 软件发行版本指南 (21) 版本控制系统（集中模式） 库与工作桌面的比较 工作桌面： 开发人员可以在本地修改维护源代码和版本控制系统中的文档。 库： 源代码的存储和修改记录集中在服务器上的版本控制系统中。 TortoiseSVN（小乌龟系统）介绍 1.文件描述 2.Windows资源管理器扩展。
版本控制系统核心操作 1.（检测） 2.（提交） 3.（更新） 4.（导入） 5.（导出） （检测）介绍 1.从库和存储在本地的版本控制系统中获取一个工作副本。 2.一次性操作 3.检测工作副本来源 4.本步骤应是第一步操作。
in sync（同步）
（提交）介绍 1.同步本地文件夹和库中的文件。 2.本地文件修改包括：文档和源代码的修改、删除和添加操作。 （提交）注意事项 1.应该一次性提交概念、功能和任务文件。 2.应该要确保提交的文件可以被成功编译。 3.将更改日志加入体骄傲信息中。
版本控制系统指南 1.工作区的所有文件夹和文件的图标都应该有一个标志来表明他们在资源管理器中的地位。 2.'.svn'文件夹保存版本信息。 版本控制系统修订编号 1.修订数字不仅表示本地工作区中的版本号也表示存储库的版本号。 2."HEAD"表示最新版本。 修改日志消息 修改版本跟踪： 1.修订版本号 2.作者 3.版本信息 4.修改的文件
（更新）介绍 1.从资源库中的修改更新到本地工作副本 2.同步存储库工作区；在同步时应该注意可能会发生冲突，版本控制系统可能会提示限制。
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-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 //显示所有在冲突解决时可能使用的命令。
Svn常见问题及相关原因 1. svn: Server sent unexpected return value (500 Internal Server Error) in response to OPTIONS request for 'https://www.doczj.com/doc/6d2546423.html,/svn/test' 错误的用户名 检查登录的用户名是否输入错误 svn: 服务器发送了意外的返回值(500 Internal Server Error)，在响应“OPTIONS” 的请求“https://www.doczj.com/doc/6d2546423.html,/svn/test” 中 2. svn: OPTIONS of 'https://www.doczj.com/doc/6d2546423.html,/svn/test': authorization failed: Could not authenticate to server: rejected Basic challenge (https://www.doczj.com/doc/6d2546423.html,) 错误的口令 用正确的用户名/口令登录 svn: 方法OPTIONS 失败于“https://www.doczj.com/doc/6d2546423.html,/svn/test”: 认证失败: Could not authenticate to server: rejected Basic challenge (https://www.doczj.com/doc/6d2546423.html,) 3. svn: Server sent unexpected return value (403 Forbidden) in response to OPTIONS request for 'https://www.doczj.com/doc/6d2546423.html,/svn/test' 用户无权限 联系管理员，为用户分配权限 svn: 服务器发送了意外的返回值(403 Forbidden)，在响应“OPTIONS” 的请求“https://www.doczj.com/doc/6d2546423.html,/svn/test” 中 4. svn: OPTIONS of 'https://www.doczj.com/doc/6d2546423.html,/svn/test': 200 OK (https://www.doczj.com/doc/6d2546423.html,) 服务器地址错误，是普通Web页面，不支持SVN的WebDAV 协议 确认输入正确的SVN 服务地址。可以在浏览器中输入该地址进行确认 svn: 方法OPTIONS 失败于“https://www.doczj.com/doc/6d2546423.html,/svn/test”: 200 OK (https://www.doczj.com/doc/6d2546423.html,) 5. The version of your subversion (client) is below 1.5.0, upgrade to 1.5.0 or above. SVN below 1.5.0 can not handle mergeinfo properly. It can mess up our automated merge tracking! 是由于客户端的软件版本低于1.5.0造成的。服务器端对客户端软件版本进行了限制，以免对合并跟踪破坏。 升级本地的Subversion客户端软件到1.5.0或以上版本。
常见错误提示： 1：?.? is not a working copy. Can?t open file ….svn/entries?:系统找不到指定的路径。 原因是输入的访问路径不正确，如svn://192.168.6.200/如果最后少写了“/”，就会出现这种错误提示。 2：将文件checkout之后，没有出现SVN的图标，是怎么回事？ 有些时候在客户端Checkout文件后，SVN的系统图标也会不显示，可以执行一下“Clean up”，就会出现SVN的系统图标。 3：为什么添加的文件，别人看不到，版本库里也没有？ 最可能的原因是，你只是执行了“Add”而没有“Commit”，这样只是在本地注明某个文件是预定要增加的，而没有实际添加到版本库中，要添加到版本库必须执行“Commit”。删除文件也是一样。 4 ：“Commit failed。……You have to update your working copy first”提交失败，需要首先执行更新操作。多人同时修改同一文件，在提交前其他人已经抢先提交到SVN服务器中，导致该错误；解决方法：对工作复本中的文件进行更新即可。 5. 更新时提示文件发生冲突：“One or more files are not a conflicted state。” 多人同时修改同一文件的同一部分，SVN无法自动进行合并，会导致该错误；解决方法：对工作复本中的文件和服务器的文件进行比较，手工合并即可。 6．“Commit failed；File already exists”提交失败，文件**已存在。 版本管理系统在改变你的计算机上的工作副本时，是非常的小心的。在做任何事情之前，它都尽可能把您的意图写到你的计算机上的日志文件中去。但如果偶然地操作中断了(例如：突然停电了，您的计算机死机了)，那么日志文件记录就可能同您最后的工作状态不一致。一种建议解决途径：先把要提交的东西拷出来放到其它目录，再更新本地文件，然后把拷出来的文件重新放回去提交。 7：执行clean up时，出现错误“Subversion reported an error while doing a cleanup!” '**' is not a working copy directory ” 遇到这种情况，先删除隐藏文件夹.svn中的tmp下面的临时文件，再执行clean up。 8：因为仓库与目录很多，使用TSVN每次选择目录URL of repository有很多地址，如何才清除呢？像清除浏览器中的历史那样，用什么方法呢？ 右键->TortoiseSVN->Settings->Saved Data，就可以清除你想要的东西了，包括URL、log、窗口大小、密码缓存等。 9：在SVN中选中一个目录show log时，出现了某些版本只显示版本号和（no date），没有其他信息，什么原因引起的？ 出现了（no date）的revision，为其他人修改了你所没有权限访问的某个目录下的文件。
【黑马程序员】svn conflict 冲突解决 1. 同一处修改文件冲突 开发人员都知道代码管理工具是开发中一个必不可少的工具，这里也不废话详细介绍了。不管你个人喜欢git还是svn还是其他，但还有一大部分公司在使用svn做代码管理工具。这里详细介绍下SVN提交文件时冲突问题的解决方式。 假设A、B两个用户，他们分别从svn服务器中检出了test1.txt文件，此时A、B、服务器三个地方的test1.txt的版本都是13(我测试环境的当前svn 赋予的版本号)。A、B文件的内容如下图(左A右B)：· 接下来，B用户添加一句话并提交，内容如下：
此时B用户和服务器的test1.txt的版本都变为14，只有A用户的test1.txt的版本还为13。接下来A用户添加一句“aa”,然后提交 由于A用户是在13版本上做的修改，而服务器已经是14版本了，所以会提交失败：
接下来就是我们要解决的问题了，解决方法分为以下两种方式。第一种方式：提交失败后直接选择revert，省去了解决冲突问题;第二种方式：提交失败后选择更新文件，这时会有冲突问题。详细介绍如下：1.1. 解决方式一 A放弃自己修改的内容，进行Revert操作，使其test1.txt成为13版本的最初内容。然后update 使其test1.txt成为14版本，再在14版本上修改提交。操作如下图：
==》 ==>然后再修改提交 1.2. 解决方式二 因为版本过时，提交失败后。A用户直接选择更新操作，结果如下图所见
(这里声明下，不要被文件显示的图标所迷惑，这是其他软件对它做了关联导致的，没啥影响)这里详细说一下产生冲突后的这几个文件，： test1.txt.mine---这个文件是A用户在13版本中做了修改要提交的文件。它的内容是：13版本内容+A用户的修改 test1.txt.r13----这个文件是A用户最初的13版本的test1.txt。它的内容是：13版本内容test1.txt.r14----这个文件时svn服务器中test1.txt的最新版本，这里既是B用户提交后的14版本。它的内容是：13版本内容+B用户的修改test1.txt--------由于A用户选择了直接更新，此文件就是svn将最新版本14 与A用户的修改合并后的文件。它的内容如下：