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

Re: New svn mergeinfo subcommand

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-09-19 22:37:56 CEST

Mark Phippard wrote:
> 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.

Yeah, I was originally thinking about making two different commands, but
having one worked too nicely.

> 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.

Eh. Whatever. Maybe this will be an excuse to expose an
svn_client_repos_root_url() function, then. :-)

> 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

[...]

> 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

I've no problem with this latter format over what's in there now, but the
inconsistent output of the first proposal is no good. You've made the
assumption that folks will copy-n-paste the eligible ranges but not the
merged ones, and frankly that assumption is bogus. I'm just as likely to
run 'svn log' on a range of merged revisions as I am to run 'svn merge' on a
range of not-yet-merged revisions, so using two different formats doesn't
strike me as anything but confusing.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Wed Sep 19 22:38:08 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.