Subversion是否合并差异或仅更新未修改文件的修订版

Question

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

我问的原因是，对于合并，SVN只需从上一次合并到头部之间获取主干的差异，然后将其应用于分支。

在许多情况下，干线中的更改远大于分支中的更改，因此从diff的大小来看，删除特征分支并创建一个修补了特征分支更改的新分支是有意义的。

当更新许多PDF时，这尤其是一个问题。

对于SVN来说，似乎另一种方式是意识到分支中的文件从未被触摸过，因此更新了它指向的修订号，而不是盲目地应用diff。

从Subversion的输出来看，似乎好像正在应用diff。

Answer 1

对于SVN来说，似乎另一种方式是意识到分支中的文件没有被触摸，因此更新了它指向的修订号。 这样可以避免diff多余的空间。

AFAIK，应用diff不会在Subversion中占用任何可观的额外空间。 如果差异较小，则仅应占用与更新修订版相似的空间量。

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

http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html

Answer 2

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

Rev: 100 
/trunk

（开店）

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

（很多变化）

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

现在，您需要做的是生成r100和r200之间的所有差异，并将它们应用于干线。 合并有点误导（ 例如文档说明 ）。 您的用例是一个相当常见的场景， 在文档中进行了介绍 。

我认为关于合并trunk-> branch或branch-> trunk没有最佳实践。 这很大程度上取决于您的工作方式和方案。 从它的声音来看，特征分支将更加不稳定。 完成功能后，将其合并到中继中将很有意义。 为了限制合并回中继时的冲突，可以从“中继”->“分支”连续合并。

Answer 3

从Subversion 1.6 CHANGES文件中：

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

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