在分支间拷贝修改
最后更新于：2022-04-02 05:56:35
### 在分支间拷贝修改
现在你与Sally在同一个项目的并行分支上工作：你在私有分支上，而Sally在主干（*trunk*）或者叫做开发主线上。
由于有众多的人参与项目，大多数人拥有主干拷贝是很正常的，任何人如果进行一个长周期的修改会使得主干陷入混乱，所以通常的做法是建立一个私有分支，提交修改到自己的分支，直到这阶段工作结束。
所以，好消息就是你和Sally不会互相打扰，坏消息是有时候分离会*太*远。记住“闭门造车”策略的问题，当你完成你的分支后，可能因为太多冲突，已经无法轻易合并你的分支和主干的修改。
相反，在你工作的时候你和Sally仍然可以继续分享修改，这依赖于你决定什么值得分享，Subversion给你在分支间选择性“拷贝”修改的能力，当你完成了分支上的所有工作，所有的分支修改可以被拷贝回到主干。
### 拷贝特定的修改
在上一章节，我们提到你和Sally对`integer.c`在不同的分支上做过修改，如果你看了Sally的344版本的日志信息，你会知道她修正了一些拼写错误，毋庸置疑，你的拷贝的文件也一定存在这些拼写错误，所以你以后的对这个文件修改也会保留这些拼写错误，所以你会在将来合并时得到许多冲突。最好是现在接收Sally的修改，而不是作了许多工作之后才来做。
是时间使用**svn merge**命令，这个命令的结果非常类似**svn diff**命令（在第3章的内容），两个命令都可以比较版本库中的任何两个对象并且描述其区别，举个例子，你可以使用**svn diff**来查看Sally在版本344作的修改：
~~~
$ svn diff -r 343:344 http://svn.example.com/repos/calc/trunk
Index: integer.c
===================================================================
--- integer.c (revision 343)
+++ integer.c (revision 344)
@@ -147,7 +147,7 @@
case 6: sprintf(info->operating_system, "HPFS (OS/2 or NT)"); break;
case 7: sprintf(info->operating_system, "Macintosh"); break;
case 8: sprintf(info->operating_system, "Z-System"); break;
- case 9: sprintf(info->operating_system, "CPM"); break;
+ case 9: sprintf(info->operating_system, "CP/M"); break;
case 10: sprintf(info->operating_system, "TOPS-20"); break;
case 11: sprintf(info->operating_system, "NTFS (Windows NT)"); break;
case 12: sprintf(info->operating_system, "QDOS"); break;
@@ -164,7 +164,7 @@
low = (unsigned short) read_byte(gzfile); /* read LSB */
high = (unsigned short) read_byte(gzfile); /* read MSB */
high = high << 8; /* interpret MSB correctly */
- total = low + high; /* add them togethe for correct total */
+ total = low + high; /* add them together for correct total */
info->extra_header = (unsigned char *) my_malloc(total);
fread(info->extra_header, total, 1, gzfile);
@@ -241,7 +241,7 @@
Store the offset with ftell() ! */
if ((info->data_offset = ftell(gzfile))== -1) {
- printf("error: ftell() retturned -1.\n");
+ printf("error: ftell() returned -1.\n");
exit(1);
}
@@ -249,7 +249,7 @@
printf("I believe start of compressed data is %u\n", info->data_offset);
#endif
- /* Set postion eight bytes from the end of the file. */
+ /* Set position eight bytes from the end of the file. */
if (fseek(gzfile, -8, SEEK_END)) {
printf("error: fseek() returned non-zero\n");
~~~
**svn merge**命令几乎完全相同，但不是打印区别到你的终端，它会直接作为*本地修改*作用到你的本地拷贝：
~~~
$ svn merge -r 343:344 http://svn.example.com/repos/calc/trunk
U integer.c
$ svn status
M integer.c
~~~
**svn merge**的输出告诉你的`integer.c`文件已经作了补丁（patched），现在已经保留了Sally修改―修改从主干“拷贝”到你的私有分支的工作拷贝，现在作为一个本地修改，在这种情况下，要靠你审查本地的修改来确定它们工作正常。
在另一种情境下，事情并不会运行得这样正常，也许`integer.c`也许会进入冲突状态，你必须使用标准过程（见第三章）来解决这种状态，或者你认为合并是一个错误的决定，你只需要运行**svn revert**放弃。
但是当你审查过你的合并结果后，你可以使用**svn commit**提交修改，在那一刻，修改已经合并到你的分支上了，在版本控制术语中，这种在分支之间拷贝修改的行为叫做*搬运*修改。
当你提交你的修改时，确定你的日志信息中说明你是从某一版本搬运了修改，举个例子：
~~~
$ svn commit -m "integer.c: ported r344 (spelling fixes) from trunk."
Sending integer.c
Transmitting file data .
Committed revision 360.
~~~
你将会在下一节看到，这是一条非常重要的“最佳实践”。
**为什么不使用补丁？**
也许你的脑中会出现一个问题，特别如果你是Unix用户，为什么非要使用**svn merge**？为什么不简单的使用操作系统的**patch**命令来进行相同的工作？举个例子：
~~~
$ svn diff -r 343:344 http://svn.example.com/repos/calc/trunk > patchfile
$ patch -p0 < patchfile
Patching file integer.c using Plan A...
Hunk #1 succeeded at 147.
Hunk #2 succeeded at 164.
Hunk #3 succeeded at 241.
Hunk #4 succeeded at 249.
done
~~~
在这种情况下，确实没有区别，但是**svn merge**有超越**patch**的特别能力，使用**patch**对文件格式有一定的限制，它只能针对文件内容，没有方法表现*目录树*的修改，例如添加、删除或是改名。如果Sally的修改包括增加一个新的目录，**svn diff**不会注意到这些，**svn diff**只会输出有限的补丁格式，所以有些问题无法表达。 但是**svn merge**命令会通过直接作用你的工作拷贝来表示目录树的修改。
一个警告：为什么**svn diff**和**svn merge**在概念上是很接近，但语法上有许多不同，一定阅读第9章来查看其细节或者使用**svn help**查看帮助。举个例子，**svn merge**需要一个工作拷贝作为目标，就是一个地方来施展目录树修改，如果一个目标都没有指定，它会假定你要做以下某个普通的操作：
1.
你希望合并目录修改到工作拷贝的当前目录。
1.
你希望合并修改到你的当前工作目录的相同文件名的文件。
如果你合并一个目录而没有指定特定的目标，**svn merge**假定第一种情况，在你的当前目录应用修改。如果你合并一个文件，而这个文件（或是一个有相同的名字文件）在你的当前工作目录存在，**svn merge**假定第二种情况，你想对这个同名文件使用合并。
如果你希望修改应用到别的目录，你需要说出来。举个例子，你在工作拷贝的父目录，你需要指定目标目录：
~~~
$ svn merge -r 343:344 http://svn.example.com/repos/calc/trunk my-calc-branch
U my-calc-branch/integer.c
~~~
### 合并背后的关键概念
你已经看到了**svn merge**命令的例子，你将会看到更多，如果你对合并是如何工作的感到迷惑，这并不奇怪，很多人和你一样。许多新用户（特别是对版本控制很陌生的用户）会对这个命令的正确语法感到不知所措，不知道怎样和什么时候使用这个特性，不要害怕，这个命令实际上比你想象的简单！有一个简单的技巧来帮助你理解**svn merge**的行为。
迷惑的主要原因是这个命令的*名称*，术语“合并”不知什么原因被用来表明分支的组合，或者是其他什么神奇的数据混合，这不是事实，一个更好的名称应该是**svn diff-and-apply**，这是发生的所有事件：首先两个版本库树比较，然后将区别应用到本地拷贝。
这个命令包括三个参数：
1.
初始的版本树（通常叫做比较的*左边*），
1.
最终的版本树（通常叫做比较的*右边*），
1.
一个接收区别的工作拷贝（通常叫做合并的*目标*）。
一旦这三个参数指定以后，两个目录树将要做比较，比较结果将会作为本地修改应用到目标工作拷贝，当命令结束后，结果同你手工修改或者是使用**svn add**或**svn delete**没有什么区别，如果你喜欢这结果，你可以提交，如果不喜欢，你可以使用**svn revert**恢复修改。
**svn merge**的语法允许非常灵活的指定参数，如下是一些例子：
~~~
$ svn merge http://svn.example.com/repos/branch1@150 \
http://svn.example.com/repos/branch2@212 \
my-working-copy
$ svn merge -r 100:200 http://svn.example.com/repos/trunk my-working-copy
$ svn merge -r 100:200 http://svn.example.com/repos/trunk
~~~
第一种语法使用*URL@REV*的形式直接列出了所有参数，第二种语法可以用来作为比较同一个URL的不同版本的简略写法，最后一种语法表示工作拷贝是可选的，如果省略，默认是当前目录。
### 合并的最佳实践
#### 手工追踪合并
合并修改听起来很简单，但是实践起来会是很头痛的事，如果你重复合并两个分支，你也许会合并*两次*同样的修改。当这种事情发生时，有时候事情会依然正常，当对文件打补丁时，Subversion如果注意到这个文件已经有了相应的修改，而不会作任何操作，但是如果已经应用的修改又被修改了，你会得到冲突。
理想情况下，你的版本控制系统应该会阻止对一个分支做两次改变操作，必须自动的记住那一个分支的修改已经接收了，并且可以显示出来，用来尽可能帮助自动化的合并。
不幸的是，Subversion不是这样一个系统，类似于CVS，Subversion并不记录任何合并操作，当你提交本地修改，版本库并不能判断出你是通过**svn merge**还是手工修改得到这些文件。
这对你这样的用户意味着什么？这意味着除非Subversion以后发展这个特性，你必须手工的记录这些信息。最佳的方式是使用提交日志信息，像前面的例子提到的，推荐你在日志信息中说明合并的特定版本号（或是版本号的范围），之后，你可以运行**svn log**来查看你的分支包含哪些修改。这可以帮助你小心的依序运行**svn merge**命令而不会进行多余的合并。
在下一小节，我们要展示一些这种技巧的例子。
#### 预览合并
因为合并只是导致本地修改，它不是一个高风险的操作，如果你在第一次操作错误，你可以运行**svn revert**来再试一次。
有时候你的工作拷贝很可能已经改变了，合并会针对存在的那一个文件，这时运行**svn revert**不会恢复你在本地作的修改，两部分的修改无法识别出来。
在这个情况下，人们很乐意能够在合并之前预测一下，一个简单的方法是使用运行**svn merge**同样的参数运行**svn diff**，另一种方式是传递`--dry-run`选项给merge命令：
~~~
$ svn merge --dry-run -r 343:344 http://svn.example.com/repos/calc/trunk
U integer.c
$ svn status
# nothing printed, working copy is still unchanged.
~~~
`--dry-run`选项实际上并不修改本地拷贝，它只是显示实际合并时的状态信息，对于得到“整体”的印象，这个命令很有用，因为**svn diff**包括太多细节。
**Subversion与修改集**
每一个人对于“修改集”的概念都有些不一样，至少对于版本控制系统的“修改集特性”这一概念有着不同的期望，根据我们的用途，可以说修改集只是一个有唯一名字的一系列修改集合，修改也许包括文件内容的修改，目录树结构的修改，或是元数据的调整，更通常的说法，一个修改集就是我们可以引用的有名字的补丁。
在Subversion里，一个全局的修订版本号N标示一个版本库中的树：它代表版本库在N次提交后的样子，它也是一个修改集的隐含名称：如果你比较树N与树N-1，你可以得到你提交的补丁。出于这个原因，想象“版本N”并不只是一棵树，也是一个修改集。如果你使用一个问题追踪工具来管理bug，你可以使用版本号来表示特定的补丁修正了bug―举个例子，“这个问题是在版本9238修正的”，然后其他人可以运行**svn log -r9238**来查看修正这个bug的修改集，或者使用**svn diff -r9237:9238**来看补丁本身。Subversion合并命令也使用版本号作为参数，可以将特定修改集从一个分支合到另一个分支：**svn merge -r9237:9238**将会合并修改集#9238到本地拷贝。
#### 合并冲突
就像**svn update**命令，**svn merge**会把修改应用到工作拷贝，因此它也会造成冲突，因为**svn merge**造成的冲突有时候会有些不同，本小节会解释这些区别。
作为开始，我们假定本地没有修改，当你**svn update**到一个特定修订版本时，修改会“干净的”应用到工作拷贝，服务器产生比较两树的增量数据：一个工作拷贝和你关注的版本树的虚拟快照，因为比较的左边同你拥有的完全相同，增量数据确保你把工作拷贝转化到右边的树。
但是**svn merge**没有这样的保证，会导致很多的混乱：用户可以询问服务器比较*任何*两个树，即使一个与工作拷贝毫不相关的！这意味着有潜在的人为错误，用户有时候会比较两个错误的树，创建的增量数据不会干净的应用，**svn merge**会尽力应用更多的增量数据，但是有一些部分也许会难以完成，就像Unix下**patch**命令有时候会报告“failed hunks”错误，**svn merge**会报告“skipped targets”：
~~~
$ svn merge -r 1288:1351 http://svn.example.com/repos/branch
U foo.c
U bar.c
Skipped missing target: 'baz.c'
U glub.c
C glorb.h
$
~~~
在前一个例子中，`baz.c`也许会存在于比较的两个分支快照里，但工作拷贝里不存在，比较的增量数据要应用到这个文件，这种情况下会发生什么？“skipped”信息意味着用户可能是在比较错误的两棵树，这是经典的驱动器错误，当发生这种情况，可以使用迭代恢复（**svn revert --recursive**）合并所作的修改，删除恢复后留下的所有未版本化的文件和目录，并且使用另外的参数运行**svn merge**。
也应当注意前一个例子显示`glorb.h`发生了冲突，我们已经规定本地拷贝没有修改：冲突怎么会发生呢？因为用户可以使用**svn merge**将过去的任何变化应用到当前工作拷贝，变化包含的文本修改也许并不能干净的应用到工作拷贝文件，即使这些文件没有本地修改。
另一个**svn update**和**svn merge**的小区别是冲突产生的文件的名字不同，在[“解决冲突（合并别人的修改）”一节]( "解决冲突（合并别人的修改）")，我们看到过更新产生的文件名字为`filename.mine`、`filename.rOLDREV`和`filename.rNEWREV`，当**svn merge**产生冲突时，它产生的三个文件分别为 `filename.working`、`filename.left`和`filename.right`。在这种情况下，术语“left”和“right”表示了两棵树比较时的两边，在两种情况下，不同的名字会帮助你区分冲突是因为更新造成的还是合并造成的。
#### 关注还是忽视祖先
当与Subversion开发者交谈时你一定会听到提及术语*祖先*，这个词是用来描述两个对象的关系：如果他们互相关联，一个对象就是另一个的祖先，或者相反。
举个例子，假设你提交版本100，包括对`foo.c`的修改，则foo.c@99是foo.c@100的一个“祖先”，另一方面，假设你在版本101删除这个文件，而在102版本提交一个同名的文件，在这个情况下，`foo.c@99`与`foo.c@102`看起来是关联的（有同样的路径），但是事实上他们是完全不同的对象，它们并不共享同一个历史或者说“祖先”。
指出**svn diff**和**svn merge**区别的重要性在于，前一个命令忽略祖先，如果你询问**svn diff**来比较文件`foo.c`的版本99和102，你会看到行为基础的区别，区别命令只是盲目的比较两条路径，但是如果你使用**svn merge**是比较同样的两个对象，它会注意到他们是不关联的，而且首先尝试删除旧文件，然后添加新文件，你会看到`A foo.c`后面紧跟`D foo.c`。
大多数合并包括比较包括祖先关联的两条树，因此**svn merge**这样运作，然而，你也许会希望合并命令能够比较两个不相关的目录树，举个例子，你有两个目录树分别代表了卖主软件项目的不同版本（见[“卖主分支”一节]( "卖主分支")），如果你使用**svn merge**进行比较，你会看到第一个目录树被删除，而第二个树添加上！
在这个情况下，你只是希望**svn merge**能够做一个以路径为基础的比较，忽略所有文件和目录的关系，增加`--ignore-ancestry`选项会导致命令象**svn diff**一样。（相应的，`--notice-ancestry`选项会使**svn diff**象合并命令一样行事。）
在将来，Subversion项目将会计划（或者发明）一种扩展补丁格式来描述目录树改变。
';