We have a repository that is seriously cluttered with the svn:mergeinfo property. I don't believe we ever used the buggy 1.5.x versions that added the property erroneously (although I could be wrong). However, due to a lax policy regarding where merges should occur, the property is now attached to files and directories all over the place. For example, when a user wants to double-commit his one-file change from release 1.3 to 1.2, he merges the change from the top-level of the 1.3 branch into the 1.2 branch and commits. The change in 1.2 appears as one text change and *137 property changes*!
Note that one complication is the fact that some users have mistakenly committed only the file changes and the top-level directory prop change, but have left the rest of the property changes uncommitted. I was hoping that the improvements in this area that are coming in 1.7 would allow us to continue to use this polluted repository, because even though it would not clean up the mess, it would not continue to create merges that look much larger than they are (due to the numerous superfluous property changes). To that end, I installed 1.7.0-rc2 with a snapshot of our repository, so I could experiment and see for myself. I did a simple merge from one branch to another. I was disappointed to see that the same miscellaneous group of files and directories below the top-level are having their snv:mergeinfo modified, even though they do not participate in the change. I guess I am not reading the documentation for 1.7 correctly, because I thought that this was one of the major changes; namely, that any object which is not affected by the merged changes would not have its svn:mergeinfo property changed. In my test, all files and directories that *currently* have svn:mergeinfo attached get the updated info from the merge being performed. This means that the backport of my one-file change looks like a much larger change. Here are my questions: 1. Assuming I don't clean up the repository, what help can I expect from 1.7 in terms of new merges? In other words, explain the behavior I should expect, given the state of my repository now and the test I performed above. 2. What other methods are recommended if 1.7 will not do what I'm hoping for? Are there any good cleanup scripts to help scrub the whole tree? (I tried mergeinfo-sanitize, to see what it was, but it did not allow me to authenticate??) 3. If I decide to simply prohibit users from making changes to svn:mergeinfo on any object besides the top-level directory itself, what are the unforeseen consequences that I need to worry about? For *this third question, *I'm not so concerned about information that might be lost during cleanup, although I know that is a huge issue. I'm more interested in the limitations this might place on us in the future, assuming we can clean up the tree completely so that *only* the top-level directory has svn:mergeinfo attached to it. For example, if a user commits two fixes using a single commit on 1.3, then wants to backport one of those fixes to 1.2, can the mergeinfo -- limited to only the top-level directory -- maintain all the information needed? Thanks, David
