subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Archer <Bob.Arc...@amsi.com>
Subject RE: cleaning up mergeinfo using svn 1.7
Date Fri, 09 Sep 2011 17:08:15 GMT
> 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

Mime
View raw message