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
Received on 2011-09-09 18:18:47 CEST