为了完成我们的例子，我们要向前一点时间。假设几天已经过去了，在主线和你的私有分支上都有了很多修改。 假设有已经完成了在你私有分支上的工作，新特性或者bug修正终于完成了，现在你想把你的分支中所有的修改都合并回 主线以便别人欣赏。

那么在这个场景下我们应怎样使用svn merge？要记得这个命令比较两个树并把差异应用到工作副本。 因此要接收修改，你应该有主线的工作副本。我们假设或者你已经有一个在那儿（完全更新了），或者你刚刚检出了一个 /calc/trunk的新的工作副本。

但是应该比较那两个树呢？初看起来，答案似乎很明显：就比较最新的主线树和你最新的分支树。但是小心—— 这个假设是错误的，已经欺骗了很多新用户！既然 svn merge 操作起来像svn diff， 比较最新的主线和分支树将不仅仅描述你对你的分支作的那些修改。这样的比较会显示太多的修改：它将不仅 显示添加了你的修改，也会显示除去了主线中那些没有发生在你的分支的修改。

为了只表达发生在你的分支中的修改，你需要比较你的分支的初始状态和最终状态。在你的分支上使用svn log， 你可以看到你的分支是在修订版341创建的。你的分支最终的状态可以简单的用修订版HEAD表示。这意味着你 要比较修订版341和你的分支目录的HEAD，并把这些差别应用到主线的工作副本。

$ svn log --verbose --stop-on-copy \
          http://svn.example.com/repos/calc/branches/my-calc-branch
…
------------------------------------------------------------------------
r341 | user | 2002-11-03 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
Changed paths:
   A /calc/branches/my-calc-branch (from /calc/trunk:340)

$

这里是最后的合并过程：

$ cd calc/trunk
$ svn update
At revision 405.

$ svn merge -r 341:HEAD http://svn.example.com/repos/calc/branches/my-calc-branch
U   integer.c
U   button.c
U   Makefile

$ svn status
M   integer.c
M   button.c
M   Makefile

# ...examine the diffs, compile, test, etc...

$ svn commit -m "Merged my-calc-branch changes r341:405 into the trunk."
Sending        integer.c
Sending        button.c
Sending        Makefile
Transmitting file data ...
Committed revision 406.

此外要注意提交日志消息中特别提到被合并到主线中的修改的范围。始终记着要这么做，因为这是你将来会用的到的关键信息。

例如，设想你决定继续在你的分支上工作一个星期，来完成你的新特性的改进或修正bug。现在资料库的HEAD修订版是480， 你完成了，并要把你的私有分支再次合并到主线。但是如“合并的最佳实践”一节中讨论的，你不想再次合并你以前已经合并过的修改； 你只想合并你的分支中所有上次合并以来的“新的”修改。这里有个技巧可以找出那些是新的。

第一步是在主线上运行svn log，来寻找关于你上次从分支中合并的日志消息：

$ cd calc/trunk
$ svn log
…
------------------------------------------------------------------------
r406 | user | 2004-02-08 11:17:26 -0600 (Sun, 08 Feb 2004) | 1 line

Merged my-calc-branch changes r341:405 into the trunk.
------------------------------------------------------------------------
…

啊哈！既然所有在修订版341和405之间发生在分支上的修改先前已经被合并到主线并成为了修订版406，现在你知道你只要合并那之后的分支修改 ——通过比较修订版406和HEAD。

$ cd calc/trunk
$ svn update
At revision 480.

# We notice that HEAD is currently 480, so we use it to do the merge:

$ svn merge -r 406:480 http://svn.example.com/repos/calc/branches/my-calc-branch
U   integer.c
U   button.c
U   Makefile

$ svn commit -m "Merged my-calc-branch changes r406:480 into the trunk."
Sending        integer.c
Sending        button.c
Sending        Makefile
Transmitting file data ...
Committed revision 481.

现在主线包含了分支里第二波的全部修改。这时，你可以删除你的分支（稍后我们会讨论），或继续在分支上工作并重复后续的合并。

svn merge另一个常见用途是回滚一个已经提交的修改。假设你在/calc/trunk一个工作副本上愉快的工作着， 你发现在以前在修订版303对integer.c做了修改是完全错误的。它不该被提交。你可以用svn merge命令来“撤销”你工作副本中的修改，然后再把本地改动提交。你要作的就是指定一个逆向的差异：

$ svn merge -r 303:302 http://svn.example.com/repos/calc/trunk
U  integer.c

$ svn status
M  integer.c

$ svn diff
…
# verify that the change is removed
…

$ svn commit -m "Undoing change committed in r303."
Sending        integer.c
Transmitting file data .
Committed revision 350.

一种看待资料库修订版的方法是把它看作一组特定的修改（有些版本控制系统称这变更集）。 通过使用-r选项，你能用svn merge来应用一个变更集、或者是一定范围内的变更集到你的工作副本。在我们这个撤销修改的情况下， 我们用svn merge来把变更集#303应用到我们的工作副本。

切记像这样回滚一个修改和其它svn merge操作一样，因此你应该使用svn status和svn diff命令来确认你的工作在你想要的状态，然后使用svn commit把最后的版本发到资料库。 在提交后，这个特定的变更集将不再反映在HEAD修订版。

此外，你可能会想：哦，实际上提交没有撤销，是吧？修改仍然存在于修订版303。如果某人检出calc 项目在修订版303和349之间的某个版本，他们仍然将看到哪个错误的修改，对吧？

是的，这是对的。当我们谈到“除去”一个修改，我们实际上在说从HEAD中除去它。 原来的修改仍然存在于资料库的历史中。在大部分情况下，这足够好了。毕竟大部分人只对跟踪HEAD有兴趣。 但也有些特殊情况，你确实想消除所有提交的痕迹（可能某人不小心提交了一个保密文档）。事实表明这不那么容易，因为 Subversion特意设计成从不丢失信息。修订版是互相依赖的不可修改的树。除去一个修订版会导致多米诺效应，对所有后续的 修订版造成混乱，还可能使所有的工作副本无效。 ^[8]

版本控制系统的一个重大的特性是信息永不会丢失。甚至在你删除了一个文件或目录时，它可能从HEAD 中去掉了，但是这个对象仍然存在于以前的修订版里。一个新用户最常问的问题之一是：“我怎么才能把我的旧 文件或目录弄回来？”

第一步是定义究竟哪个是你要恢复的项。这有个有用的隐喻：你可以把资料库中的每一个对象想象为 存在于一种两维坐标系统中。第一个坐标是一个特定的修订版树，第二个坐标是这个树中的一个路径。 因此你文件或目录的每个修订版都可以用一个特定的坐标点来定义。

Subversion 没有像CVS那样的Attic目录。 ^[9] 因此你需要使用svn log 来发现你想恢复的项的精确坐标。一个好策略是在曾经包含你删掉的项的目录中运行svn log --verbose。--verbose选项显示每个修订版中所有修改了的项的列表。所有你需要做的 是找到你删除文件或目录的哪个修订版。你可以直接寻找，或者使用别的工具来检查日志输出（用grep，或者在编辑器 中用增量搜索）。

$ cd parent-dir
$ svn log --verbose
…
------------------------------------------------------------------------
r808 | joe | 2003-12-26 14:29:40 -0600 (Fri, 26 Dec 2003) | 3 lines
Changed paths:
   D /calc/trunk/real.c
   M /calc/trunk/integer.c

Added fast fourier transform functions to integer.c.
Removed real.c because code now in double.c.
…

在这个例子里，我们假定你在寻找一个删除了的real.c文件。通过检查父目录的日志，你已经发现 这个文件是在修订版808被删除的。而且，文件存在的最后一个修订版就是这个修订版之前的那个。结论： 你想从修订版807恢复/calc/trunk/real.c。

以上是困难的部分——查找。现在你知道你要恢复什么了，你有两个不同的选择。

一个选项是用svn merge来“逆向”应用修订版808（我们已经讨论过怎样撤销修改， 参见“撤销修改”一节）。这将导致把real.c作为一个本地修改重新添加。 这文件将被预订添加，在提交后，这个文件会再次出现在HEAD中。

但是，在这个特殊的例子里，这可能不是最好的策略。逆向应用修订版808将不仅预订添加real.c， 日志消息也显示了这也会撤销对文件integer.c的某些修改，而这是你不想的。当然，你可以逆向合并 修订版808然后svn revert对integer.c的本地修改，但这种技术不好大规模应用。 如果在修订版808有90个文件修改了会怎样？

另一种更目标明确的策略是根本不要用svn merge，而是用svn copy命令。 仅仅从资料库把准确的修订版和路径指定的“坐标点”复制到你的工作副本。

$ svn copy --revision 807 \
           http://svn.example.com/repos/calc/trunk/real.c ./real.c

$ svn status
A  +   real.c

$ svn commit -m "Resurrected real.c from revision 807, /calc/trunk/real.c."
Adding         real.c
Transmitting file data .
Committed revision 1390.

状态输出中的加号表示这一项不仅预订要添加，而且预订“带着历史”添加。Subversion记录它是从哪儿复制来的。 将来，在这个文件上执行svn log会回溯到文件的恢复并一直到它在修订版807之前的所有历史。换句话说，新文件real.c 不是真的新，它是原来的被删除了的文件的后代。

虽然我们的例子是恢复一个文件，但是要说明的是同样的技术也可以用来恢复删除了的目录。

版本控制最常用于软件开发，因此这里简单介绍两个在程序员团队中最常用的分支/合并模式。如果你不是用Subversion 、来做软件开发， 跳过这节也没关系。如果你是头一回使用版本控制的软件开发者，要认真阅读，因为这些模式通常被有经验的人们认为是最佳实践。 这些过程不是特定于Subversion的；它们对任何版本控制系统都有效。同样，用Subversion的术语来描述有助于理解它们。

$ cd trunk-working-copy

$ svn update
At revision 1910.

$ svn merge http://svn.example.com/repos/calc/trunk@1910 \
            http://svn.example.com/repos/calc/branches/mybranch@1910 \
U  real.c
U  integer.c
A  newdirectory
A  newdirectory/newfile
…