> 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.
It is possible that if you committed those property changes the mergeinfo would be elided. You may want to run a record-only merge, this should elide and extra mergeinfo that is on the child nodes. Afaik. BOb > > 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
