0

这个例子来自 SVN 1.8。

我们使用带有主干和特征分支的通用技术。通常，功能分支是通过分支主干创建的。通过合并从主干到功能分支（变基）的更改，功能分支不断与主干保持同步。当功能分支中的开发完成后，内容将合并回主干。

当功能分支合并回主干时，对功能分支的所有更改，包括由 rebase 创建的更改，都记录在主干文件/文件夹的 svn:mergeinfo 属性中。这样做的一个后果是，当功能分支合并回主干时，功能分支中尚未更新的文件和文件夹（通过变基除外）被标记为已更改（仅限属性）。

为什么这是必要的？主干日志显示，当功能分支合并回主干时，这些文件夹/文件发生了更改，尽管功能分支中相对于主干没有文件夹/文件内容发生更改。这对我们的开发人员来说是相当混乱的，因为 TortoiseSVN 显示很多他们没有更改的文件夹/文件已经更新。这真的是理想的行为吗？

4

1 回答 1

0

SVN 在合并跟踪方面实际上并不是很聪明。它只真正关注“您告诉我合并哪些版本”而不是“这些版本中的更改最初来自哪里”。您告诉 SVN 合并整个分支；所以 SVN 就是这样做的，将该分支上的每个版本记录为合并。

也就是说，您可以采取措施消除一些开销。如果您总是只从项目的顶级文件夹进行合并，那么您甚至只会在该顶级文件夹上拥有 mergeinfo；你不会有一堆带有属性集的子文件夹和文件。听起来您在进行“rebase”合并时必须在项目中精心挑选特定文件和文件夹。如果您可以避免这样做，您的日志数据应该看起来更干净，只有顶级文件夹属性会为您的最终合并而更改。

于 2016-06-10T17:06:31.473 回答