Re: Problem in svn log -g output

On 6/13/07, Daniel Rall <dlr@collab.net> wrote:
> 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.

Just to add to the confusion, pburba did get the same problem as me on
his Windows system.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org