On Tue, 25 Oct 2005, David Anderson wrote:
> kfogel@collab.net wrote:
> > Why not just do it with -r?
> > (Have we already discussed this? It feels vaguely familiar...)
>
> It has indeed already been discussed. I believe the consensus became
> that if -r is to do it, it should do it perfectly consistently across
> *all* commands. Which breaks, since some commands already assume a
> meaning for a single-revision -r.
>
> I feel it's better to add a switch that does one thing consistently
> (when it's available of course), instead of making the behaviour of
> another switch look pseudorandom. That also seemed to be a major
> argument against the use of -r last time.
But the semantics of -r are already inconsistent across commands:
'svn log -r 37' means something entirely different than 'svn diff -r 37'.
The option parsing code specifies revisions in ranges. If one of the
revs in the range is not specified, the command itself has always dictated
the semantics, and these semantics are not consistent across commands.
<soapbox>
Personally, I find the existing behavior of 'svn diff -r 37' completely
broken and unintuitive. Case in point: Does that command use the range
0:37, or 37:HEAD, or...? Sure, some of you knew the answer -- but I bet
those that did have looked at (or written!) the source code, had to read
the help, or have been through this exercise before.
Though I'm usually the one to rear the head of the backwards compatibility
monster, in this particular case my personal preference is strongly on the
side of completely changing the semantics of this command to the more
intuitive behavior being suggested for the -c flag. This behavior is so
intuitive that it's what 'svn log -r 37' already does (!), so it would
actually significantly improve consistency across commands.
</soapbox>
Obviously, changing the semantics of -r for 'diff' and 'merge' is not
backwards compatible. Since I'm unlikely to convince the rest of you to be
bad kids and fix the semantics of -r, having Yet Another Switch (-c) is an
acceptable -- though unpalatable -- work around to achieve what should
already be the behavior of -r.
> Also, another advantagelet imho: it makes the svn cmdline UI almost
> compatible with svk's (no picking of multiple revs with -c yet, ie.
> -c1234,2932,4823). It'd make interoperating between the two for my poor
> brain easier.
This is certainly a point in -c's favor. However, wouldn't the long form
then be better as --changes (instead of --change)?
- Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 26 23:53:13 2005