Re: Remaining Merge Tracking auditing features for 1.5

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]

So basically:

  * "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
mergeinfo proposal?

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

-- 
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org