SVN分支与合并中修改问题专家详解

本节接着上节继续向大家简单介绍一下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]