为什么不合并任何更改的svn合并分支会导致未修改的文件修改svn:mergeinfo属性 [英] Why would svn merge of a branch with no changes causes untouched files to modify svn:mergeinfo property
问题描述
我从主干创建了一个名为"feature3"的分支.我对"feature3"分支上的文件进行了零修改.中继上的文件也没有任何修改.使用TortoiseCVS(TortoiseSVN 1.6.6，内部版本17493-32位)针对SVN(版本1.6.3(r38063))存储库，我启动了合并"，并选择了重新集成分支"选项.
I have created a branch called "feature3" from my trunk. I make zero modifications to files on the "feature3" branch. There are also no modifications to files on trunk. Using TortoiseCVS (TortoiseSVN 1.6.6, Build 17493 - 32 Bit) against a SVN (version 1.6.3 (r38063)) repo, I initiate a "Merge" with the "Reintegrate a branch" option selected.
此命令的输出显示已合并80个文件.这些文件上唯一更改的是svn:mergeinfo属性.但是，为什么只有这80个文件?我在项目中还有数百个其他文件，但都没有更改此属性.
The output of this command shows 80 files merged. The only thing changed on these files is the svn:mergeinfo property. But why only these 80 files? I have hundreds of other files in the project that didn't have this property changed.
以下是单个文件中svn:mergeinfo属性更改的示例
Here is an example of the change to the svn:mergeinfo property on a single file
之前:
/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/分支机构/升级/库/安全性/规范/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/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/分支机构/升级/库/安全性/规范/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/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
所做的更改是已添加此行
The changes are that this line was added
/trax/branches/feature3/Libraries/Security/Specifications/NotSpecification.cs:11328-11334
/trax/branches/feature3/Libraries/Security/Specifications/NotSpecification.cs:11328-11334
最后一行已修改
/trax/trunk/Libraries/Security/Specifications/NotSpecification.cs:6672-9851,11324-11327
/trax/trunk/Libraries/Security/Specifications/NotSpecification.cs:6672-9851,11324-11327
我希望合并将导致零个文件被合并. 为什么SVN会认为这些文件需要合并并且其svn:mergeinfo属性已更改?有办法解决这个问题吗?
I expected that the merge would result in zero files being merged. Why would SVN think that these files need to be merged and their svn:mergeinfo property changed? Is there a way to correct this?
在这种情况下，我应该删除所有80个文件上的svn:mergeinfo属性吗?我指的是此处和
Is this a case where I should delete the svn:mergeinfo properties on all 80 files? I am alluding to here and here.
这个简单的示例是较大调查的一部分，在该调查中，我创建了一个功能分支，进行了一些更改，然后尝试将更改合并回主干.但是，合并通知我在这80个文件上发生了几棵树冲突.由于所有这些树冲突，我无法使用SVN分支，这一切令人非常沮丧.
This trivial example is a part of a larger investigation in which I create a feature branch, make several changes and then attempt to merge changes back to the trunk. However, the merge informs me of several tree conflicts on these same 80 files. This is all very frustrating that I cannot use SVN branching due to all these tree conflicts.
推荐答案
但是为什么只有这80个文件?
But why only these 80 files?
这些文件具有svn:mergeinfo属性；其他人没有.当单个文件和项目子文件夹具有此名称时，它称为子树mergeinfo".文件或文件夹具有"svn:mergeinfo"属性后，合并信息将在每次合并操作中更新.
These files have a svn:mergeinfo property; the others don't. When individual files and project subfolders have this, it is called "subtree mergeinfo". Once a file or folder has a "svn:mergeinfo" property, the mergeinfo will be updated on each merge operation.
如果仅在项目的根目录上进行合并，并使用SVN客户端的最新版本，则很少会看到子树mergeinfo.仅项目分支的根文件夹(例如/trunk，/branches/foo)应具有svn:mergeinfo属性.
If you merge only on the root of your project, and use the latest version of the SVN client, you will rarely see subtree mergeinfo. Only the root folder of the project branches (e.g. /trunk, /branches/foo) should have a svn:mergeinfo property.
编辑:如果仅删除子树mergeinfo，则Subversion不知道合并发生了.作为consquence，颠覆可能再次尝试合并这些修改只要让它挑选符合自动合并的版本(例如，当你做一个<4>不specififying的
edit: If you simply delete the subtree mergeinfo, then subversion doesn't know that the merge happened. As a consquence, subversion might try to merge these revisions again whenever let it pick the revisions eligible for merging automatically (e.g. when you do a svn merge without specififying the -r or -c options). In the worst case such a merge attempt might generate some spurious conflicts, which is not a big problem; just resolve them manually.
更新:Subversion 1.7现在仅在必要时更新mergeinfo.从发行说明:
update: Subversion 1.7 now only updates mergeinfo when it is necessary. From the release notes:
如果子树不受合并影响，则合并不再在子树(具有自己的显式mergeinfo)上记录mergeinfo(描述合并).对于拥有大量带有显式mergeinfo的子树的用户，这将大大减少虚假svn:mergeinfo属性更改的次数.
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.
这篇关于为什么不合并任何更改的svn合并分支会导致未修改的文件修改svn:mergeinfo属性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
