Daniel Rall <dlr@collab.net> writes:
> While this functionality could be delivered by piggy-backing on
> existing sub-commands ('svn log' and 'svn info' have been considered
> at length), discussion leads me to believe that we might be better off
> introducing a new sub-command to deliver these features:
>
> svn mergeinfo --available-from=URL TARGET[@REV]
> svn mergeinfo [-r ARG] [--merged-from | --merged-to] TARGET[@REV]
"--available-from" is a synonym for "--unmerged-from", right?
By the way, why don't URL take an @REV qualifier in the first example?
If the --merged-from target in the second example can take @REV, I
would have though URL in the first example could too.
I'm not sure what the semantics of the "-r ARG" are.
> The output of "Change Set Merge Availability" will look like that of
> 'svn log'. The semantics will be slightly different, listing logs
> from URL instead of from TARGET.
Have we considered piggy-backing on 'svn merge' itself?
1. svn merge --info-unmerged FROM_URL TARGET[@REV]
2. svn merge --info-merged-from TARGET[@REV]
3. svn merge --info-merged-to TARGET[@REV]
In fact, even if the subcommand were "mergeinfo", I would still like
to offer the above option structure for consideration.
> The output of "Find Change Set" will include merging revision, URL,
> and range list:
>
> $ 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
For a moment I almost proposed "r30-r57", but I guess that takes up
too much horizontal space (and is completely idiosyncratic).
> $ svn mergeinfo --merged-from /branches/featureX
> At r14, merged r3-7, r13 from /branches/featureX to /trunk
>
> $ svn mergeinfo --merged-to -r37
> At r60, merged r30-57 from /branches/featureY to /trunk
>
> $ svn mergeinfo --merged-from -r37
> At r60, merged r30-57 from /branches/featureY to /trunk
>
> $ svn mergeinfo --merged-to -r37 /trunk
> At r60, merged r30-57 from /branches/featureY to /trunk
>
> $ svn mergeinfo --merged-from -r37 /trunk
>
> (Nothing was merged *from* /trunk in r37, only *to* it.)
In real life, these lines are very often going to overflow 80 columns.
Perhaps we should declare now (for parsers) that whitespace at the
beginning of a line means a continuation line, and format like this...
$ svn mergeinfo --merged-from /branches/featureX
At r14, merged r3-7, r13
from /branches/featureX
to /trunk
$
...whenever the result would otherwise overflow 75 or whatever
columns.
> The only other viable alternative would be to introduce multiple new
> sub-commands: one to handle the path/revs output by
> --merged-from/--merged-to, and another to handle the 'log'-style
> output from --available-from. This offers the benefit of consistent
> output from a sub-command regardless of the options it's passed
> (arguably similar to the modal behavior of --xml), but has the obvious
> down-side of introducing yet more sub-commands that a user must wrap
> their head around.
You have been working on and thinking about this far more than I, but
the words "only other viable alternative" still make me nervous... :-)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 3 03:04:25 2007