在前面的章节中，我们提到你和Sally都在各自的分支中对integer.c作了修改。如果你 察看在修改版344写的日志消息，你可以看到她修正了一些拼写错误。无疑，你的同一文件的拷贝仍然有同样的 拼写错误。可能你将来的修改影响这些有拼写错误的地方，因此可能会在以后某天合并你的分支时导致冲突。那么， 更好的办法是，在你在相同的地方做太多的工作之前，现在就接收Sally的修改，。

现在是使用svn merge命令的时候了。这个命令是svn diff命令 （你在第三章读到过）的很近的表兄弟。这两个命令都可用来比较资料库中任何两个对象。例如，你可以 让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的副本被修补了。 现在它包含了Sally的修改——修改已经从主干“复制”到你的私有分支了，现在就如你的 本地修改一样。这时，你需要检查本地的修改来确认它是正确的。

在另一个场景中，可能事情没那么顺利，integer.c会进入到冲突状态。 你可能需要用标准的过程（参见第三章）来解决冲突，或者如果你认定合并完全是个坏主意， 那么可以简单的放弃它，并用svn revert恢复本地的修改。

假设你已经检查完了合并后的修改，你可以像平常一样用svn commit提交修改。 这时，修改已经被合并到你的资料库分支里。在版本控制术语中，在分支之间复制修改通常被称为移植（porting） 修改。

当你提交本地修改时，应该确认你的日志消息记录了你从一个分支移植了某个特定的修改到另一个分支， 例如：

$ svn commit -m "integer.c: ported r344 (spelling fixes) from trunk."
Sending        integer.c
Transmitting file data .
Committed revision 360.

如你在下一节将看到的,这是一个应该遵循的、重要的“最佳实践”。

$ 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 diff和svn merge在概念上很相似，但是很多情况下它们有不同的语法。 一定要阅读第九章以得到更多的细节，或者使用svn help。例如，svn merge需要一个工作副本路径作为目标，就是说，要有一个它能应用树修改 的地方。如果没有指定目标，它假设你在尝试执行以下某个常用操作之一：

如果你在合并一个目录而且没有指定目标路径，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