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.
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.
Here is an example of the change to the svn:mergeinfo property on a single file
Before:
/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
After
/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
and the last line was modified
/trax/trunk/Libraries/Security/Specifications/NotSpecification.cs:6672-9851,11324-11327
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?
Is this a case where I should delete the svn:mergeinfo properties on all 80 files? I am alluding to here and here.
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.
But why only these 80 files?
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.
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.
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.
update: Subversion 1.7 now only updates mergeinfo when it is necessary. From the 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.
Where Did That Mergeinfo Come From?
The above is probably the best starting point reference for why you sometimes get that type of mergeinfo behavior. The Submerged blog has some ESSENTIAL svn merging knowledge stored in it.
While I have not read this next post, this one looks potentially helpful for you as well:
来源：https://stackoverflow.com/questions/2051267/why-would-svn-merge-of-a-branch-with-no-changes-causes-untouched-files-to-modify