How do I avoid large number of svn:mergeInfo when merging trunk to a feature-branch in SVN

Question

I am trying to keep a feature branch up to date by merging trunk into the branch. Problem is, that about 2000 files that was there when the branch was created, and that has been left untouched on both the branch and on trunk is getting updated with nothing but svn:mergeinfo. The project is rather large in scale, and the impact on our SVN history is so big, that it renders the merge commit history unusable as it is marking literally thousands of files changed, even though the only change to these files, is done by SVN itself.

I have tried

• Using the same client version as the Repo ( 1.5.2 )
• Using my current client version 1.6.10
• Merging a range of revisions, from branch start till head

I should mention, that I've been looking closely at the SVN documentation when trying this. So no rules should be broken ( eg. no switched subtrees, clean local copy etc.)

Blush

Answer 1

Bascially to clean up the repository you need to run the following on your integration branch so that the change fans out from there:-

C:> svn propdel svn:mergeinfo –R

i.e. you do it in the trunk so that future release and feature branches are not polluted. When merging existing branches you can ignore all svn:merginfo changes below the "merge root" as they will be inherited anyway.

I wrote a blog on this issue a while back which covers it in more detail:-

Cleaning up svn:mergeinfo Droppings http://chrisoldwood.blogspot.com/2010/03/cleaning-up-svnmergeinfo-droppings.html

Kalidasa

thank you for this more in-depth explanation of how to get rid of it. – Blush

While deleting mergeinfo is a frequently used approach, it isn't the RightWay(tm) to do it; see slowdog's answer for more on this. – Protective

Answer 2

svn will add mergeinfo properties to individual files if it thinks their merge history differs from that of their parent directory. Once that has happened, every subsequent merge, no matter how harmless, will cause those mergeinfo properties to be updated. I found the first half of this article helpful to understand why that happens.

If you want to avoid these constant mergeinfo changes, you'll have to "tidy up" the existing mergeinfo properties on your branch. The safest, but most laborious, way is to run svn propget -R svn:mergeinfo on the branch, and then study the differences between the mergeinfo on individual files and the mergeinfo of their parent directory. You may find that the differences are small, and that "svn merge"ing a small number of individual revisions will be enough to trigger mergeinfo elision, causing all the individual mergeinfo properties to disappear.

If you're confident you understand how mergeinfo works, you can also just wade in and manually edit or remove the mergeinfo from the offending files.

Spill

My understanding, based mostly on this article: collab.net/community/subversion/articles/merge-info.html is, that I should never edit the svn:mergeInfo by hand..? – Blush

I would say you shouldn't edit mergeinfo by hand unless you understand what you're doing and why you're doing it. Merging specific revisions into particular directories to get the mergeinfo changes you want (i.e. more uniform mergeinfo, so that every file no longer changes with each merge) is a much better idea, and usually all you need. Using the "--record-only" option is the next-"naughtiest" method. Manual editing is the last resort. In a larger sense, none of this "should" be necessary: svn's mergeinfo elision should be cleverer than it is. Maybe in a few years it will be :-/ – Spill

See also this very detailed article. – Protective

Answer 3

If you have such mergeinfo on files which aren't really changed you or someone else does merges not from the working copy root...The only solution is to removed the svn:mergeinfo from the files, cause the only location is in the working copy root nowhere else. And one other point you should update the repository to 1.6.X ..

Photographer

Will updating the repository eliminate these problem, or are you just thinking best practice ? – Blush

Also, If I avoid the sub-tree merging going forward, will I escape these problems? Or will the merge-info hazzle haunt me forever? – Blush

Answer 4

As I am not confident with blind svn:merge-info property deletion, I have implemented a tool to analyze the current situation on a working copy and remove as much merge revisions as possible from non-root merge-info properties. After additional human checks and controls, the changes on the working copy can be committed.

Here it is: svn-clean-mergeinfo

Do not hesitate to report any issue about its usage to get it improved.

Rodney