[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problem in svn log -g output

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: 2007-06-13 22:56:42 CEST

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.

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?

- -Hyrum
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 13 22:53:22 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.