On 04/07/2007 0.14, Daniel Rall wrote:
>> In that case, I assume that a bare "svn mergeinfo" means "show me all
>> revisions that have been merged into the current trunk".
> So, a bare 'svn mergeinfo' defaults to 'svn mergeinfo --merged-to .'
> While I like that a lot, the UI would be inconsistent with our other
> sub-commands, which don't have a "default behavior" for which they
> also have a long option. I'm +1 on the behavior, but we need to alter
> the UI for consistency with other sub-commands.
I understand your concern. I think this command better describe my vision:
svn mergeinfo [-r ARG] [--from URL[@REV]] TARGET[@REV]
* "svn mergeinfo": show all the merges into the current directory
* "svn mergeinfo foo": show all the merges into foo
* "svn mergeinfo --from=bar foo": show all the merges from bar into foo
Does this sound better? Or am I still missing something wrt your original
>> So, my own suggestion is to use two different commands. I don't think
>> that's harder on users than having a single command with two
>> totally-different meanings, triggered by special options on the command
>> line. On the contrary, I think it's easier for them.
>> svn mergeinfo [-r ARG] [--merged-from | --merged-to] TARGET[@REV]
>> svn mergeavail [--from URL] TARGET[@REV]
> So, a bare 'svn mergeavail' would show available revisions for all
> paths which have been merged into TARGET? That sounds very useful.
Yes. Indeed it is.
>>> $ svn mergeinfo --merged-to /trunk
>>> At r14, merged r3-7, r13 from /branches/featureX to /trunk
>>> At r60, merged r30-57 from /branches/featureY to /trunk
>> Please, use an output which is *very* machine-oriented. Most users will be
>> better off using a graphical merge tool anyway (what's "r14", "r3", "r13"?
>> A graphical merge tool can just show you those graphically).
> Do you find --xml to be insufficient (or do you just not like XML)?
> (I wouldn't blame you for that. ;-)
No, XML is perfectly fine for me. I had not understood it was implied that
--xml existed :)
In fact, I really prefer parsing XML that an under-specified format like (eg)
that of a normal "svn log". I wonder how many people failed into the trap of
parsing "svn log -v", and realizing after some time that they failed to take
into account the copyfrom info :) [ it happened *twice* to me ]. Or, even
easier, parsing "svn st" and crashing because of svn:externals :) This kind of
parsing mistakes just can't happen with XML.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Jul 4 01:26:57 2007