Re: Problem in svn log -g output

On Wed, 13 Jun 2007, Hyrum K. Wright wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mark Phippard wrote:
> > Hyrum,
> >
> > This is a quick follow-up to what we discussed this AM on IRC.
> >
> > Now that I have the new log API integrated into Subclipse it is easy
> > to see the results you get back. The problem I think I am seeing is
> > that the log API must just be religiously reporting the change the
> > mergeinfo as the revisions that were merged.
> >
> > The problem is that the MT code will collapse revision ranges whenever
> > possible. So it might enter a revision range of 1-10 but the path
> > being reported might have only been changed in a couple of those
> > revisions. Using my sample repository as an example:
> >
> > svn log -g -r 6 $REPOS/trunk
> > ------------------------------------------------------------------------
> > r6 | merger | 2007-05-25 20:16:28 -0400 (Fri, 25 May 2007) | 1 line
> >
> > Merge branch a. Added medium product.
> > ------------------------------------------------------------------------
> > r5 | copier | 2007-05-25 20:14:33 -0400 (Fri, 25 May 2007) | 1 line
> > Result of a merge from: r6
> >
> > Create branch c
> > ------------------------------------------------------------------------
> > r4 | auser | 2007-05-25 20:13:35 -0400 (Fri, 25 May 2007) | 1 line
> > Result of a merge from: r6
> >
> > Create page for medium product.
> > ------------------------------------------------------------------------
> >
> > Notice how the spurious r5 has slipped into the output? This is
> > because when /branches/a was merged into trunk at r6, the mergeinfo
> > property was changed as such:
> >
> > Property changes on: .
> > ___________________________________________________________________
> > Name: svn:mergeinfo
> > Merged /branches/a:r4-5
> >
> > For the log -g option to be correct it would have to determine that r5
> > did not impact /branches/a and simply ignore it in the output.
> >
> > I think this would resolve most of the problems I reported.
>
> Mark,
> Agreed that the behavior you propose is correct. Problem is, as
> mentioned in IRC last night, it's also the behavior that I'm already
> seeing, and I have trouble fixing what I can't duplicate.
>
> We've had this unreproducibility problem before, so I'd like to get a
> third opinion. Does anybody else get r5 when running 'svn log -g -r6
> branches/b' inside of the CollabNet sample mergetracking repository?

I was not able to reproduce this on my Fedora Core 6 laptop at the
office (with either regular or XML output). However, Mark and I
confirmed that we have the same data in our mergeinfo.db for r6, which
I found somewhat surprising.