本节接着上节继续向大家简单介绍一下SVN分支与合并问题，主要内容有SVNmerge用法取消修改，SVN与修改集以及如何找回删除的项目等，希望本文的介绍对大家的学习有所帮助。下面是SVN分支与合并具体介绍。
取消修改
SVNmerge另一个常用的做法是取消已经做得提交，假设你愉快的在/calc/trunk工作，你发现303版本对integer.c的修改完全错了，它不应该被提交，你可以使用svnmerge来“取消”这个工作拷贝上所作的操作，然后提交本地修改到版本库，你要做得只是指定一个相反的区别。（你可以通过指定--revision303:302--change-303
$svnmerge-c-303http://svn.example.com/repos/calc/trunk
Uinteger.c
$svnstatus
Minteger.c
$svndiff…
#verifythatthechangeisremoved…
$svncommit-m"Undoingchangecommittedinr303."
Sendinginteger.c
Transmittingfiledata.
Committedrevision350.
我们可以把版本库修订版本想象成一组修改（一些版本控制系统叫做修改集），通过-r选项，你可以告诉svnmerge来应用修改集或是一个修改集范围到你的工作拷贝，在我们的情况例子里，我们使用svnmerge合并修改集#303到工作拷贝。SVN分支与合并中取消修改问题介绍完了，我们再来看一下SVN与修改集的问题。
SVN与修改集
每一个人对于“修改集”的概念都有些不一样，至少对于版本控制系统的“修改集特性”这一概念有着不同的期望，根据我们的用途，可以说修改集只是一个有***名字的一系列修改集合，修改也许包括文件内容的修改，目录树结构的修改，或是元数据的调整，更通常的说法，一个修改集就是我们可以引用的有名字的补丁。
在SVN里，一个全局的修订版本号N标示一个版本库中的树：它代表版本库在N次提交后的样子，它也是一个修改集的隐含名称：如果你比较树N与树N-1，你可以得到你提交的补丁。出于这个原因，想象“版本N”并不只是一棵树，也是一个修改集。如果你使用一个问题追踪工具来管理bug，你可以使用版本号来表示特定的补丁修正了bug—举个例子，“这个问题是在版本9238修正的”，然后其他人可以运行svnlog-r9238来查看修正这个bug的修改集，或者使用svndiff-r9237:9238来看补丁本身。SVN的合并命令也使用版本号作为参数，可以将特定修改集从一个分支合到另一个分支：svnmerge-r9237:9238将会合并修改集#9238到本地拷贝。记住回滚修改和任何一个svnmerge命令都一样，所以你应该使用svnstatus或是svndiff来确定你的工作处于期望的状态中，然后使用svncommit来提交，提交之后，这个特定修改集不会反映到HEAD版本了。
继续，你也许会想：好吧，这不是真的取消提交吧！是吧？版本303还依然存在着修改，如果任何人取出calc的303-349版本，他还会得到错误的修改，对吧？
是的，这是对的。当我们说“删除”一个修改时，我们只是说从HEAD删除，原始的修改还保存在版本库历史中，在多数情况下，这是足够好的。大多数人只是对追踪HEAD版本感兴趣，在一些特定情况下，你也许希望毁掉所有提交的证据（或许某个人提交了一个秘密文件），这不是很容易的，因为SVN设计用来不丢失任何信息，每个修订版本都是依赖其它修订版本的不可变目录树，从历史删除一个版本会导致多米诺效应，会在后面的版本导致混乱甚至会影响所有的工作拷贝。[22]
找回删除的项目
SVN分支与合并介绍一下如何找回删除的项目。版本控制系统非常重要的一个特性就是它的信息从不丢失，即使当你删除了文件或目录，它也许从HEAD版本消失了，但这个对象依然存在于历史的早期版本，一个新手经常问到的问题是“怎样找回我的文件和目录？”。
***步首先要知道需要拯救的项目是什么，这里有个很有用的比喻：你可以认为任何存在于版本库的对象生活在一个二维的坐标系统里，***维是一个特定的版本树，第二维是在树中的路径，所以你的文件或目录的任何版本可以通过这样一对坐标定义。（记住常见的“peg修订版本”语法—foo.c@224—在前面的“Peg和实施修订版本”一节提到过。）
首先，你需要svnlog来察看你需要找回的坐标对，一个好的策略是使用svnlog--verbose来察看包含删除项目的目录，--verbose选项显示所有改变的项目的每一个版本，你只需要找出你删除文件或目录的那一个版本。你可以通过目测找出这个版本，也可以使用另一种工具来检查日志的输出（通过grep或是在编辑器里增量查找）。
$cdparent-dir
$svnlog-v…
------------------------------------------------------------------------
r808|joe|2003-12-2614:29:40-0600(Fri,26Dec2003)|3lines
Changedpaths:
D/calc/trunk/real.c
M/calc/trunk/integer.c
Addedfastfouriertransformfunctionstointeger.c.
Removedreal.cbecausecodenowindouble.c.…
在这个例子里，你可以假定你正在找已经删除了的文件real.c，通过查找父目录的历史，你知道这个文件在808版本被删除，所以存在这个对象的版本在此之前。结论：你想从版本807找回/calc/trunk/real.c。
以上是最重要的部分—重新找到你需要恢复的对象。现在你已经知道该恢复的文件，而你有两种选择。
一种是对版本反向使用svnmerge到808（我们已经学会了如何取消修改，见“取消修改”一节），这样会重新添加real.c，这个文件会列入增加的计划，经过一次提交，这个文件重新回到HEAD。
在这个例子里，这不是一个好的策略，这样做不仅把real.c加入添加到计划，也取消了对integer.c的修改，而这不是你期望的。确实，你可以恢复到版本808，然后对integer.c执行取消svnrevert操作，但这样的操作无法扩大使用，因为如果从版本808修改了90个文件怎么办？
所以第二个方法不是使用svnmerge，而是使用svncopy命令，精确的拷贝版本和路径“坐标对”到你的工作拷贝：
$svncopy-r807\
http://svn.example.com/repos/calc/trunk/real.c./real.c
$svnstatus
A+real.c
$svncommit-m"Resurrectedreal.cfromrevision807,/calc/trunk/real.c."
Addingreal.c
Transmittingfiledata.
Committedrevision1390.
加号标志表明这个项目不仅仅是计划增加中，而且还包含了历史，SVN记住了它是从哪个拷贝过来的。在将来，对这个文件运行svnlog会看到这个文件在版本807之前的历史，换句话说，real.c不是新的，而是原先删除的那一个的后代。尽管我们的例子告诉我们如何找回文件，对于恢复删除的目录也是一样的。本节关于SVN分支与合并问题介绍完毕。
【编辑推荐】
