On Wed, 04 Jul 2007, Giovanni Bajo wrote:
> 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 [-r ARG] [--from URL[@REV]] [--xml] [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?
This example provides an excellent interface for determining "merged
from" information. However, it doesn't accommodate ease of discovery
of "merged to" information.
Use case: I have a set of live branches still under maintenance, and I
want to know where I've backported a bug fix to. Rather than going to
each branch and asking about the bug fix's change set, I want to just
ask the repository where the change set has been merged to.
What were you thinking for 'svn mergeinfo --merged-to'?
> >>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.
I'm really leaning towards adding more sub-commands to handle this
features. Anyone else have thoughts on this?
> >>> $ 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 :)
Gotcha. I think we have it for most client sub-commands that report
information to the user. Adding it for merge info auditing/reporting
will be trivial.
> 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.
I do find XML to suite this particular case quite well.
- application/pgp-signature attachment: stored
Received on Thu Jul 5 22:04:07 2007