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