> 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
Received on 2011-09-09 19:08:49 CEST