Question

我们有一些功能分支，可以一次放在冰上几个星期。在主干中进行了许多更改后，最好将更改从主干合并到分支中，或者删除分支并直接从主干创建新分支，并将更改从起始分支复制到其中。

我问的原因是，对于合并，SVN只需将上一次合并的主干差异应用于头部并将其应用于分支。

在许多情况下，主干中的更改远远超过分支中的更改，因此根据差异的大小，删除功能分支并创建一个新功能分支更改已修补的内容是有意义的。

当更新大量PDF时，这尤其是一个问题。

似乎另一种方式是SVN意识到分支中的文件从未被触及，因此更新它所指向的修订号，而不是盲目地应用差异。

从Subversion的输出看起来好像它正在应用差异。

Answer 1

似乎是另一种方式 SVN实现了一个文件分支没有被触及因此更新它指出的修订号至。这样可以避免额外的空间对于差异。

AFAIK，应用diff不会在subversion中占用任何显着的额外空间。如果差异很小，那么它应该仅仅采用与更新版本相似的空间量。

顺便说一下，从主干到分支合并？只有当你计划稍后将分支合并回主干时才有意义。

Answer 2

我认为你使用Subversion的方式可能不正确（我之前做过这个）。您需要做的是将一系列修订合并到您的主干中。例如：

Rev: 100 
/trunk

（建立分支机构）

Rev:101 
/trunk (r100) 
/branch (r101)

（很多变化）

Rev: 200 
/trunk (r100)
/branch (r200)

现在您需要做的是生成r100和r200之间的所有差异并将它们应用到主干。合并有点误导（like the documentation states）。您的用例是一个相当常见的场景，covered in the documentation。

我认为没有关于是否合并trunk-＆gt; branch或branch-＆gt; trunk的最佳做法。它非常依赖于您的工作方式和您的方案。从它的声音，功能分支将更加不稳定的主干。一旦完成功能，合并到主干是有意义的。为了在合并回主干时限制冲突，您可以从trunk-＆gt;分支继续合并。

Answer 3

来自Subversion 1.6 CHANGES文件：

相同的文件共享存储库中的存储空间（问题＃2286）

因此，似乎即使应用了diff，在提交时，代码也应该发现相同的文件，只使用指向文件第一版的指针。