如何在重新整合时删除挥之不去的svn：mergeinfo属性？

Question

I wanted to work on a small set of changes independent from my other development on a project. I've been using this as a guide.

I started off by doing a svn cp from /trunk/app/module to /branches/pete/feature-branch, this was r393

After some changes, and merges from back and forth between the trunk and branch to keep things up to date, I was finished with my feature, and went back to working on the trunk.

A couple few revisions later, I decided maybe I should clean up my feature branch so I tried to reintegrate it.

1. I checked out a fresh copy of the feature branch and trunk.
2. I merged the trunk changes into the feature branch and committed them
3. I then did a merge --reintegrate ^/branches/pete/feature-branch on the trunk resulting in r434

Everything looks OK from the code point of view, but now my trunk/app/module still has a svn:mergeinfo property.

$ svn pg svn:mergeinfo
/branches/pete/feature-branch:393-433

From what I understand, svn:mergeinfo should be empty and these revisions should be "elided" or is this OK ?

Answer 1

This information on the subfolder shows you that you (accidentally?) merged on a subfolder (not on trunk, but on /trunk/app/module).

Subversion knows now that it will not merge these revisions from this branch again. Usually you should only merge on the topmost folder, so the mergeinfo is only on this folder.

To merge only a subdirectory is not recommended by SVN-Team ( See SVN book topic here )

Avoid subtree merges and subtree mergeinfo. Perform merges only on the root of your branches, not on subdirectories or files (see the section called “Subtree Merges and Subtree Mergeinfo”) .

Still all merges are possible, but you end up with a lot of (different) mergeinfos on different folderlevels, which makes it later harder to figure out what is going on and why SVN behaves this way.

Also it is always possible (not recommended!) to delete the merge-info property, to "reset" the mergetracking feature. Mostly done by also deleting the branch as well. Then the risk of a second merge is usually negligible.