How to avoid svn:mergeinfos on sub-folders?

Question

We try to keep the 'svn:mergeinfo' property on the root branch folder only. However, we keep seeing it creep into subfolders. We've been able to identify some possible causes:

1. Moving a folder in the repo-browser
2. Moving and/or renaming packages in IntelliJ
3. Using old svn clients

Can anyone provide a list of things we should not do in order to avoid creating these properties by accident?

The tools we are using are IntelliJ 8 (soon 9), Ankh, TortoiseSVN and SlikSvn.

Napalm

Answer 1

We wrote a SVN hook/trigger that simply rejects commits to svn:properties on non-trunk. We never looked back.

Napalm

Could you share the hook script? – Inhuman

@WinstonSmith - I no longer work at the same company, so I don't have access to the hook. If it's really important to you I can try and ask around, but it should be very trivial to implement (if not, just ask a question here on how to do it). – Napalm

Answer 2

Unfortunately, old svn clients just do this, and any tools that are based on these old versions of svn are also broken. The only way to resolve this issue is to delete the created svn:mergeinfo entries before they are committed. Since most people are not aware that they are created, then the only real way to enforce that is a pre-commit hook, or just simply do:

svn propdel --recursive svn:mergeinfo $ROOT/*

to clean them out every now and then. Be careful when doing this, as it will destroy any record of partial merges that you have done, so you should really only do this if you really don't do partial merges. The questioner does not, and nor do we in our environment.

The problem is fixed in the newer svn clients, so the problem should slowly die out, but that could take some time before all of the tools in your workflow are replaced.

Based on another answer to this question, a quick explanation of what causes the problem. When you do a working copy move or delete svn clients older than 1.5.5 created a spurious svn:mergeinfo entry. This is resolved in svn 1.5.5.

Priestcraft

Doesn't this destroy existing merge info, or is the merge info redundant there? – Holman

In our case the mergeinfo was redundant. But you are right it will destroy ant partial merge info that you have done. – Priestcraft

updated answer to mention this problem, and to describe the problem, and when it was resolved. – Priestcraft

Answer 3

I can't provide such a list. I would recommend you to use svn hook that will log user action that leads to folder property change and either issue a warning or reject that commit, whatever is appropriate according to your workflow.

Thorp

Answer 4

Performing merges on subfolders or individual files causes this, and it should cause it, because it has to record merge information.

Best way is to perform your merges at the main level, and when needed to selectively apply it, revert the changes you don't want merged, and then commit.

Holman

I am getting this property even without doing any merges on subfolders. – Napalm

To whoever downvoted, please supply a reason for that? Not merging at sub-levels is vital if you want your merge info at the main level only. – Holman

I didn't downvote you, however while what you say is correct, the problem is that copies were also generating these entries. This was fixed in 1.5.5 (* do not create mergeinfo for wc-wc moves or copies (r34184, -585)) – Priestcraft