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

Problem in svn log -g output

From: Mark Phippard <markphip_at_gmail.com>
Date: 2007-06-12 23:28:29 CEST


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 Phippard
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 12 23:28:38 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.