svn-冲突处理、增量打包

一、冲突处理

一个S，多个C，多个C同时修改了某一行，导致SVN不知道该用哪一个，就有可能发生冲突。这里的C不是指用户，而是指提交代码的客户端，即使这几个客户端用的是同一个账号。

比如C1在v1.0的版本上改的，C提交时，S上的版本被C2更新到v1.1，当C1提交时，SVN不知道该用哪一个作为v1.1。
比如C1和C2同时修改了某一行，C1提交了，C2更新，就会冲突。

有2种情况会导致冲突

• commit时
  某一行在本地是1版本上改的，但远程是2版本
• update时
  某一行在本地是1版本上改的，但远程是2版本

1.文本

svn报冲突时，如果用tortoisesvn这个客户端，会在本地文件夹生成3个文件：mine、r4、r5，有冲突的源文件也会添加黄色叹号。
此时打开1.txt，会发现svn把自己本次修改的部分，本次修改之前，别人跟自己本次修改冲突的 这3部分都给标识了出来。

处理方式有2种：

1.1.把自己修改的部分回滚，然后更新，然后再修改

使用revert(回滚)操作，该操作表示用户放弃自己的更新代码，然后直接commit，这个时候你的代码就会是服务器上最新的代码，即A用户提交的新代码，你的代码不会被提交。也就是说，此处虽然点了commit，但实际上是先update操作。

1.2.手动处理冲突

这种方法需要冲突双方经过协商之后将代码更改统一之后再提交。

{1}选择文件->右键Editconficts

选中文件右键：

有几个选项：

• Edit confilicts：手动修改冲突。
• Mark as resolved：直接标记为已解决，这样会删除.mine、.r1、.r2这些文件，但这只是标记，如果你直接标记为解决，实际上文件还是冲突的，只是状态修复了，再提交还是会报错。
• Resolve conflict using ‘theirs’：使用远程版本覆盖本地来解决冲突。如果你的修改不需要提交，你可以方便的选择这个。
• Resolve conflict using ‘mine’：使用本地版本覆盖远程版本来解决冲突。如果对方提交的代码没什么用，你可以直接使用这个来解决。

{2}进入冲突处理对话框。

分为3部分，左上theirs表示当前服务器端最新的代码，右上Mine表示自己修改后的代码，下面Merged表示冲突处理后的代码。

如果你的界面显示了很多格式字符(比如换行)，你可以点击顶部的“Show Whitespaces”来隐藏。

左上的第12行下面的绿色等号表示这行被删除了，背景为黄色
13、14行前面的+号表示这两行是新增的
右上的同样也是删除了一行，然后增加了第13行

merged区域的13，14行显示的是红色背景的一串???..，表示SVN这行不知道用哪一个，暂时用???..占位。

merged中的所有内容都可以手动修改，包括很多？？？，merged中的内容就是最新版，svn会用这一版覆盖server上的当前版本。

假设我们将本地的修改作为13行，14行使用他人提交的。那么选中右上的第13行，右键选择“Use this text block”，表示使用这行的代码，此时merged区域的13行变为绿色。
Use this text block：使用这块代码为合并后的行，block就是行
Use this whole file：使用这整个文件作为合并后的文件
Use text block from ‘mine’ before ‘theirs’：两边的代码都保留，我的代码在前面
Use text block from ‘theirs’ before ‘mine’：两边的代码都保留，我的代码在后面

选中左上的14行，右键选择“Use this text block”。这样就搞定了，下面区域会显示合并后的效果

{3}无论是使用右键选项还是手动修改，merged中没有红色行之后，表示可以提交，点击顶部工具栏的“Mark as resolved”标记为已解决好冲突，或者直接ctr+s保存也会提示“Mark as resolved”菜单，此时生成的3个冲突文件会自动删除，只保留源文件

{4}如果是更新报的冲突，此时已经处理完毕。如果是提交报的冲突，关闭对话框，再次提交

2.word

word不是文本，git和svn都没法完美管理，但svn可以调用word自带的审阅功能。

2.1.edit confilict example

在节点1新建一个word1，添加111，提交
在节点2update，并追加222
在节点1的word1中再追加333，此时，无论commit还是update，都会冲突conflict
冲突后，点击edit conflict，会自动弹出word自带的冲突处理器，在合并栏处理完后，点击上面审阅里的确定修改，然后save as 改为源文档一样的名字替换原来的同名文档。此时生成的rxx结尾的冲突文件会自动删掉，此时提交就可以了

3.excel

3.1.edit confilict example

excel没有自带的冲突处理器，如果点击edit conflict，会报不是文本文件的错。此时只能手动跟其他同事沟通，合并后把冲突文件删掉，再提交就可以了。冲突处理完的文件，svn会认为是最终版本，会直接替换掉服务器上的同名文件。

二、还原到之前的某版本

冲突发生时如果采取的措施不对可能会导致部分代码丢失，如果想要还原之前的代码。
选择文件->右键选择show log在这里面你可以看见之前提交的所有版本
找到你想要恢复的版本右键选择revert to this version 就可以恢复了

三、增量打包（不使用基线）

1.通过commit log获取2次commit之间的added和modified，然后将这些文件保存到指定目录，再把这个目录打包，然后到时直接解压即可。最早的那个commit就叫基线。

2.example1

{1}在某目录下添加一个带文件的目录和一个文件，提交

{2}show log，选中增量的区间，右键compare revisions

如果只选中一个commit log，则没有compare revisions，而是compare with previous revision。

{3}选中added的和modified的，Export selection to 到指定目录

点击 Export selection to，保存到指定的目录（根目录一般叫tags，每次增量目录叫path_版本号_年月日）（一般不放在本地仓库中，因为下次打增量包，会把tags目录也打进去）。此时，tags目录下的path_1555_20200628 下就有增量文件，打包后就可以作为下发介质了。

四、增量打包（使用基线）

1.基线实际上就是标记，一个快照，在svn中使用分支来实现基线。

2.svn推荐的根目录是branches、tags、trunk

3.process

{1} 第一次上线，项目目录整理完，创建一个基线保存在tags下

{2} 第二次上线时，再次创建一个基线，然后比较2个基线的版本，提取出增量部分，然后就可以打包下发了。