svn - 为什么SVN合并没有任何更改的分支会导致未修改的文件修改SVN :mergeinfo property

Question

我从主干创建了一个名为“feature3”的分支。我对“feature3”分支上的文件进行了零修改。中继上的文件也没有任何修改。使用针对SVN(版本1.6.3(r38063))存储库的TortoiseCVS(TortoiseSVN 1.6.6，内部版本17493-32位)，我启动了“合并”，并选择了“重新集成分支”选项。

该命令的输出显示已合并的80个文件。这些文件上唯一更改的是svn:mergeinfo属性。但是，为什么只有这80个文件？我在项目中还有数百个其他文件，没有更改此属性。

这是在单个文件上更改svn:mergeinfo属性的示例

前:

/trax/branches/current/Libraries/Security/Specifications/NotSpecification.cs:10292-10783 /trax/branches/feature1/Libraries/Security/Specifications/NotSpecification.cs:11324 /trax/branches/feature2/Libraries/Security/Specifications/NotSpecification.cs:11326 /trax/branches/int/Libraries/Security/Specifications/NotSpecification.cs:11232-11314 /trax/branches/next/Libraries/Security/Specifications/NotSpecification.cs:10156-10782 /trax/branches/trax-1.0.x/Libraries/Security/Specifications/NotSpecification.cs:10191-10291 /trax/branches/upgrade/Libraries/Security/Specifications/NotSpecification.cs:9964-10604 /trax/tags/trax-1.0.0/Libraries/Security/Specifications/NotSpecification.cs:10178-10190 /trax/trunk/Libraries/Security/Specifications/NotSpecification.cs:6672-9851,11232-11325

后

/trax/branches/current/Libraries/Security/Specifications/NotSpecification.cs:10292-10783 /trax/branches/feature1/Libraries/Security/Specifications/NotSpecification.cs:11324 /trax/branches/feature2/Libraries/Security/Specifications/NotSpecification.cs:11326 /trax/branches/feature3/Libraries/Security/Specifications/NotSpecification.cs:11328-11334 /trax/branches/int/Libraries/Security/Specifications/NotSpecification.cs:11232-11314 /trax/branches/next/Libraries/Security/Specifications/NotSpecification.cs:10156-10782 /trax/branches/trax-1.0.x/Libraries/Security/Specifications/NotSpecification.cs:10191-10291 /trax/branches/upgrade/Libraries/Security/Specifications/NotSpecification.cs:9964-10604 /trax/tags/trax-1.0.0/Libraries/Security/Specifications/NotSpecification.cs:10178-10190 /trax/trunk/Libraries/Security/Specifications/NotSpecification.cs:6672-9851,11324-11327

所做的更改是已添加此行

/trax/branches/feature3/Libraries/Security/Specifications/NotSpecification.cs:11328-11334

最后一行被修改了

/trax/trunk/Libraries/Security/Specifications/NotSpecification.cs:6672-9851,11324-11327

我希望合并将导致零文件被合并。 为什么SVN会认为这些文件需要合并并且其svn:mergeinfo属性已更改？有没有办法纠正这个问题？

我是否应该在所有80个文件上删除svn:mergeinfo属性？我指的是 here和 here。

这个琐碎的示例是较大调查的一部分，在该调查中，我创建了一个功能分支，进行了几次更改，然后尝试将更改合并回主干。但是，合并通知我在这80个文件上发生了几棵树冲突。由于所有这些树冲突，我无法使用SVN分支，这一切都非常令人沮丧。

Answer 1

But why only these 80 files?

这些文件具有 svn:mergeinfo属性；其他人没有。当单个文件和项目子文件夹具有此名称时，它称为“子树mergeinfo”。文件或文件夹具有“svn:mergeinfo”属性后，合并信息将在每次合并操作中更新。

如果仅在项目的根目录上进行合并，并使用SVN客户端的最新版本，则很少会看到子树mergeinfo。仅项目分支的根文件夹(例如 /trunk， /branches/foo)应具有 svn:mergeinfo属性。

编辑:如果仅删除子树mergeinfo，则subversion不知道合并发生了。作为consquence，颠覆可能会尝试，只要让它挑选符合(当你做一个 svn merge没有specififying的 -r或 -c选项例如)自动合并的版本再合并这些修订。在最坏的情况下，这种合并尝试可能会产生一些虚假的冲突，这不是一个大问题。只需手动解决它们。

更新:Subversion 1.7现在仅在必要时更新mergeinfo。从 release notes:

Merges no longer record mergeinfo (describing the merge) on subtrees (that have their own explicit mergeinfo), if the subtree was unaffected by the merge. This should greatly reduce the number of spurious svn:mergeinfo property changes for users who have large numbers of subtrees with explicit mergeinfo.