> -----Original Message-----
> From: Bob Archer [mailto:Bob.Archer_at_amsi.com]
> Sent: Tuesday, June 28, 2011 2:20 PM
> To: Michael Fletcher; users_at_subversion.apache.org
> Subject: RE: Apparently Spurious svn:merginfo
>
> > We are having problems with a large number of svn:mergeinfo
> > properties
> > being modified each time we merge. These svn:mergeinfo are on
> > unrelated
> > files to the actual change being made. Though it does seem as if
> > they
> > correlate to prior merges that have happened. If we commit these
> > property changes they will happen again the next time we merge.
> >
> > At this point when we merge we will see 80 files with svn:mergeinfo
> > changed when we might only be merging one file. It's becoming
> > difficult
> > to determine what exactly we have changed.
> >
> > I looked in the FAQ and googled and nothing exactly seemed to match
> > what
> > we are seeing.
> >
> > Mostly, we have TortoiseSVN 1.6.8 / Subversion 1.6.11 on the client
> > and
> > svn 1.6.15 on our server. The repository is old, having had nearly
> > every major version of SVN that ever existed.
> >
> > We merge sometimes from our "trunk" to a branch and sometimes from
> > our
> > branches back to trunk. We often have multiple releases in flight
> > so a
> > fix will be merged from ^/branches/7.00.39 to ^/branches/7.00.40
> > and
> > then to ^/branches/7.00.41 and then to ^/trunk. Or the reverse.
> >
> > At some point people were reverting the svn:mergeinfo properties
> > and
> > performing the checkin because they didn't know what they did.
> > Nobody
> > should be doing that any more.
> >
> > Any help would be appreciated.
>
> This is a pretty common complaint people have, I'm surprised you
> couldn't find any threads about it. If I were writing an svn merging FAQ
> this would probably be question number 1 or 2.
>
> What is most likely happening is that you have mereinfo on your child
> nodes that is not present in your root node. This usually happens when
> someone does a merge for a specific file or folder rather than doing the
> merge at the project root.
>
> I was going to write all about this, but quickly was able to find this
> article on line that saves me much typing.
>
> http://blog.syntevo.net/2011/03/16/1300268640000.html
>
> BOb
It looks like the 1.7 merge command will make the problem a bit better in at least two ways.
1) It will only update mergeinfo on sub-trees that were affected in the merge, even if other sub-trees have mergeinfo properties. (I am probably not doing full justice to this change -- see http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording.)
2) As the same link shows, the merge command will be more verbose about when it is updating meta-data versus merging content.
Often times, people only merge a sub-tree because they know that the branch they worked on only changed content in that one tree. That's fine, but it adds more mergeinfo at the sub-tree level, instead of at the branch level. If you want to elide mergeinfo on lower levels, you can run record-only merge(s) at the higher level so that the mergeinfo property goes away at lower levels without actually removing data (you just move it up to a higher level). Of course you have to do the research to verify it is a safe/correct thing to do for that particular circumstance.
I was headed down this path before getting side-tracked on to other work. One useful thing to know is which branch meta-data is different from one sub-tree to another. I just started comparing merge info on directory path versus another via this little script:
#!/bin/bash
dir=$1
if [[ $1 = "." ]]
then
svn pg svn:mergeinfo $1
else
svn pg svn:mergeinfo $1 | sed -e "s,/$1:,:,"
fi
That gives output stripped of relative path info so that they can be directly diff'ed to see which merges are missing in which sub-trees. Caveat: I am not sure that's a valid comparison in the future 1.7 world.
-Steve
Received on 2011-06-28 23:46:52 CEST