tortoiseSVN 进阶知识

以前一直是无脑update和commit，遇到冲突修改就修改。
最近仔细把tortoiseSVN 文档给看了下，居然有300多页，虽然翻译得过于生硬，但也了解到不少版本控制逻辑的智慧。这里用我的理解做个笔记。TortoiseSVN功能尊是出乎意料的强大啊。。。Subversion而之后还有更加强大的github。。。

重要操作

-

Update和commit

这里两个操作是版本控制的基础。
对于文件的内容改动检查，这里的处理方式分多种情况：

1.当本地和服务器没有任何修改：

两种操作都无效果

2.当本地被修改，服务器库没有被修改：

update不会做出任何动作。Commit会把你的文件提交，服务器版本号+1

3.本地被修改，服务器库也被修改：（他人提交了其他版本）：

最复杂的一种情况
在先commit的情况下，svn会通知你先执行update。
一、Update会智能的检测对照，如果被修改的地方不同，自动合并2处的修改。
之后再commit，会把合并完的文件提交，服务器版本号+1。
二、如果被修改的地方相同（同文件同一行），执行update，会通知“in a conflicted state”产生了冲突。
冲突文件被标记感叹号，需要人工处理。这时右击，选择edit conflicts，下端的文本框红色？？？处标志冲突区域，右击可以选择 theirs，mine或者两者合并内容。

4.当本地没有被修改：服务器被修改时：

Update会修改你的副本使其与服务器一致，commit无任何执行。

以上的流程比单纯的读写锁更合理

树冲突的处理
文件树的冲突处理比文件内容更复杂。—此处待更新

- Checkout时的一些选项

很多时候我们checkout并不想要版本库中的全部版本，那么可以在checkout对话框中选择检出的范围。

范围依次是全部检出，只检出子文件夹和当前目录中文件，只检出当前目录中文件，只检出空文件。
之后还有choose item的选项，可以明细的检出特定任何几个文件。
另外在之后的update和commit时，会智能的只针对特定范围深度和文件来提交，更新，非常方便。

- 分支/切换/合并

另一个超级重要的功能，可以说是业务救星
通常对于团队而言，如果不开分支和tag就直接多人修改同一项目，那么冲突往往会令人崩溃。测试无从谈起。对于个人而言，开发个性化软件，会有一个已经开发好的历史基础稳定版本，依据此版本再做2次开发乃至3次。但是如果业务过多，一些好的修改如新增库很难合并到基础版并分发到其他版本。甚至会版本混乱。这时候就要使用分支/合并。

###- 分支：

在基础版上右击->tortoiseSVN->branch/tag 填入子路径
如/tags/wangzhan 就生成了一个分支版本。注意子路径是区分大小写的。Wangzhan和wangzhan不同。

###- 标记

标记和branch原理和操作都是一样的，但是tag是保留一份静态的版本库，通常放在tag下的路径。Branch是时时修改的，标记/分支的区别主要是在逻辑上。

如果勾上了就会完成后自动转入分支。

###- 切换：

没什么好说的，使用switch就可以切换。这里有个小技巧就是如果整个项目过大，又经常有切换操作，可以复制一个现有project，再switch切换，可以减少网络传输。

###- 合并

合并前的准备：
1合并前先提交一个版本，使得项目全为绿勾。
2**合并始终在本地进行，合并前本地是什么目录（主/分支），合并后仍为此主或分支。合并后提交才有用。**

合并的处理步骤其实非常复杂。

合并分为3种：

####- Merge a range of revisions

合并范围版本 最常用的一种合并方法。
计算一个被你选择的分支/主干，即你下一步中选择的目录。将这个分支/主干的修改应用到当前本地project上。
因此这种合并类似提取并打补丁，把其他分支/主版本的改动，应用到本地project

其中revision range to merge可以选择特定版本或版本范围的改动。空为合并全部修改。格式如下。类似word打印页码时候的选择规则。

另外最后如果带上@3表明本地project以3版本为基础应用其他分支的修改。

注意：
1如果想合并已被删掉的分支，要回滚到分支存在的版本。
2勾选reverse merge可以反向合并，类似去补丁。
3 1.5版本之前会存在重复合并的问题。1.5之后由于引入合并跟踪，会智能判断哪些版本已合并。但还是推荐在合并时候记录你合并过的版本号。

####- Merge two different trees

这种方法比较少用。而且具体业务逻辑复杂。
合并2个树 把A版本合并到B版本。一般是对比较成熟的分支才做的事情。**

另一种情况是对付vendor branches。（这里貌似指的是含外部svn库的供应商分支，而第三方也在更新）。因为第三方供应商的程序数据你是不会去动的。但常常会被第三方更新。而且对于更新后比较稳定的供应商分支，结合你自己的代码测试后你才会想合到你的主干中来。

对话框写作：from A to B。如下图

其实根据AB的路径，分多种情况。但是文档里只规定了一种写法即方法2。
怀着实验的心情测试了下：

1、AB相同：

无意义，无操作

2、A为与当前目录所指的svn路径相同，B为分支

A被变得和B一模一样。
常用的合并法。这时注意A如果是主干，那么它的branches等文件夹也和B一样。。也就是分支全部没了。因此要慎重。

3、当前目录所指SVN路径与AB不同，A为分支1，B为分支2：

以当前目录文件树为基准，应用B的改动。
添加当前目录中没有而B中有的文件。
默认保留当前目录有而B中没有的文件。
A独有的新文件不会添加到当前目录。
如各版本存在一个同名被修改文件，此文件以A为基准，如产生冲突，让你选择如何解决。

4、B与与当前目录所指的svn路径相同，A为分支：

没什么意义。会被标记冲突，但解决时默认保留所有当前目录的东西。
如果对这种合并有点不大理解，可以参考git的rebase概念http://git-scm.com/book/zh/v1/Git-分支-分支的衍合

###- Reintergrate a branch

复兴合并
貌似这个方法非常冷门。下面只是作为记录。
这种合并为Merge two different trees的特形，按shift右键会有tortoiseSVN- merge reintergrate选项,会将所有分支修改应用到主干上。前提是主干在生成分支后没有做任何修改或者主干更改已合并到分支。
文档里说：
复兴合并需要满足一些条件。首先，服务器必须支持合并跟踪。工作副本必须为完全递归 (不是有限的检出深度)，而且它不能具有任何本地修改、交换项目或已更新为最新版本之外的其他版本的项目。分支开发过程中的所有主干更改必须已合并到分支 (或标记为已合并)。要合并的版本范围将自动被计算。

冲突的处理

很多时候合并时会造成冲突。这时候会弹出解决冲突对话框。

如果是2进制文件，点击前2个按钮会让你保留本地或者服务器库中文件。如果是文本文件，会优先在冲突位置使用本地或者服务器库中片段。
不过通常情况下，我们都会点击 edit conflict来自己看看。手动设定好解决方案后，再选择resolved即可。
最后一行选项就延迟该文件/延迟余下所有文件的解决。但如果该文件在接下来的合并中有进一步的更改，它将无法完成合并。比如多个版本都修改了此文件。

其他一些较为重要的知识

删除/添加/改名/移动/复制

尽量使用svn的add 和delete来对付文件。以免提交时忘记勾选导致没进版本控制的麻烦。
如删除时候想保留本地文件，只是在版本控制中移除可以shift 右击来操作，选择delete(keep local)

尤其是改名/复制/移动时，简单使用windows命令会丢失这个文件的一系列SVN历史版本记录。导致无法追溯。要使用svn的rename命令。而在移动或复制时候，要使用windows的剪切或复制命令后，在目标文件夹使用svn的paste命令。
另一种情况是IDE中改名等时候，svn同样无法获知这个文件是被改名或移动的，这时候就需要在commit对话框里ctrl多选这2个文件，右击repair move来关联文件
这里要注意的是，移动或改名后要记得立即提交父文件目录。因为如果其他人这时候提交了一个新版本，你commit时会出现没有删除这个被移动的文件却在目标地多了一个文件的囧境。
另外如果有本地project有外部svn库（svn:externals），则需要使用windows的一系列操作。因为你对这个svn库操作svn命令的话，实际上容易引发其他库的不良变动。

回滚至特定版本，并从此版本开始为修改基准

有一个偶尔会遇到的操作，就是想如上面说的一样，回滚到特定版本，继续修改。但这里有个大坑：
普通的对 文件夹根目录使用右击->update to revision （填入特定版本号）进行的回滚，只能作为查看特定版本的方法。如果你想从此版本开始为修改基准继续commit是无法成功的。最多只能告诉你文件 out of date。
这时候就要牢记操作：右击->tortoisSVN->show log 打开更新日志，然后右击想要回滚的版本号，选择revert to this version，之后commit。 被回滚后提交的版本日志，会以蓝色加粗字体显示。

Status 为Missing的文件处理

本地先增加一个文件，标记为add，再直接删除文件，这时候commit时，会报 is scheduled for addition, but is missing 的错误。全部选中后右击，执行revert，才会成功的将这几个文件取消掉。

追溯

对一个文件使用Svn-blame可以查看文件的历史改动，谁修改了什么。非常实用。

补丁

这是给没有修改服务器库权限的人的一个功能。右键svn-patch会生成一个版本改动补丁文件，提交给管理员。使用apply patch即可。

日志的字体

用特殊符号环绕文本，就可以有一些样式上的变化。对于重要的地方可以使用。
星号文本星号表示粗体，下划线文本下划线 表示下划线，^文本^表示斜体。

拖放

这个功能如果不看文档很可能就没用过。
1写日志时可以给下方的文件列表拖动到日志框，会填充文件的绝对路径。
2（适用于一个庞大的project，改动了几个文件后commit，如果对根目录直接commit或update，那么文件检查耗时会让人失去耐心。）对一个文件进行commit，显示对话框。这时候对一个本地project打开多个窗口，把其他几个文件或文件夹拖入，同样也可以commit。

使用正则表达式查找

通常只要有筛选过滤的地方就可以输入正则表达式查找。不过和Perl 兼容正则表达式
规则有点不同。。 详细说明
http://www.regular-expressions.info/

Clean up

此功能也并不常用，但是非常有用。在一次不成功的svn操作（如commit时候断电，死机等）导致事务没有顺利完成，cleanup相当于一次回滚操作。解除目录锁。

Import和export

导进到库和导出到本地。看字面的话有时候会弄混目标。
这2个命令并不常用，
Export获取纯净的资源
Import不推荐用因为有2个缺点：容易出现文件层级错误，并且导进库后本地文件夹并不能自动成为新库的项目副本，而仍然是以普通文件夹存在。