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

New svn mergeinfo subcommand

From: Mark Phippard <markphip_at_gmail.com>
Date: 2007-09-19 20:19:49 CEST

cmpilato committed a new svn mergeinfo subcommand that reports the
merged and available revisions. Here are some output samples:

$ svn mergeinfo .
Path:
  Merge source: file:///Users/username/repositories/conflicts/trunk
    Merged ranges: r0:4, r8:9, r12:16, r21:22
    Eligible ranges: r4:8, r9:12, r16:21, r22:25

$ svn mergeinfo .
Path:
  Merge source: file:///Users/username/repositories/merge-tracking/branches/a
    Merged ranges: r3:11
    Eligible ranges: r11:17
  Merge source: file:///Users/username/repositories/merge-tracking/branches/b
    Merged ranges: r10:17
    Eligible ranges:

So there are a few questions up for debate.

1) Currently it shows both merged and eligible ranges. Now that I
see it, I like this idea. I imagine we could add --avail and --merged
as options if we didn't want it to be this way. I like the way it is.

2) He writes out full URL's. The svn:mergeinfo property uses
relative URL's (for good reason). I understand why he is using full
URL's. I think the output would be more readable if it was relative
to the root. I would not change the API, just the CLI output. I do
not feel strongly about this.

3) He shows revision ranges in the format we currently support for
svn merge. I say currently because issue 2818 might impact this.

Merge itself, now outputs the actual revisions it is merging. The
mergeinfo property describes the actual revisions that are merged. I
kind of prefer this myself to the other format. I know on IRC some
people have questioned this (at least in terms of the merge output).
They think it should be consistent with the input to merge. I
understand that argument but think the current output makes more sense
to the user and situation.

So what should this command do?

(I am going to use the term "old format" to mean the way svn merge
currently accepts a revision range. And "new format" to refer to the
way svn:mergeinfo records it.)

Something that would be both consistent and inconsistent at the same
time would be to use the "new format" for reporting merged revisions,
and the "old format" for the eligible ranges. This would allow the
eligible revision range to be passed directly to svn merge if desired.
 This might sound stupid, maybe it is, but I think it does make some
sense from a user perspective and overall consistency.

Here is what the above output would look like:

$ svn mergeinfo .
Path:
  Merge source: /trunk
    Merged revisions: 1-4, 9, 13-16, 22
    Eligible ranges: r4:8, r9:12, r16:21, r22:25

$ svn mergeinfo .
Path:
  Merge source: /branches/a
    Merged revisions: 4-11
    Eligible ranges: r11:17
  Merge source: /branches/b
    Merged revisions: 11-17
    Eligible ranges:

And for completeness, here is what it would look like if we simply
used the "new format" for both:

$ svn mergeinfo .
Path:
  Merge source: /trunk
    Merged revisions: 1-4, 9, 13-16, 22
    Eligible revisions: 5-8, 10-12, 17-21, 23-25

$ svn mergeinfo .
Path:
  Merge source: /branches/a
    Merged revisions: 4-11
    Eligible revisions: 12-17
  Merge source: /branches/b
    Merged revisions: 11-17
    Eligible revisions:

I changed the word "ranges" to be "revisions" when reporting using the
"new format" and also dropped the r and : in favor of a -

-- 
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
Received on Wed Sep 19 20:19:59 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.