[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Issue 1351] New - svn -r 939 log vs. svn -r 939 diff inconsistency

From: Chris Stork <cstork_at_ics.uci.edu>
Date: 2003-06-07 03:44:17 CEST

On Fri, Jun 06, 2003 at 02:19:43PM -0500, Ben Collins-Sussman wrote:
...
> Here's the point of the current behavior:
>
> A diff compares two trees. You must specify two trees to compare.

Agreed.

> But "svn diff -rN" only specifies one tree.
 
Of course, that depends on your choice of sensible default values for
the second tree.

> One option is disallow that syntax completely... that would be
> "purist". You would still be able to see changesets by examining
> -r N-1:N.
>
> But then we have no way to compare the working-copy to a revision
> tree. We have no 'WC' keyword, as in 'svn diff WC:535'. So we
> decided to make -r535 a shorthand for this use-case, rather than the
> "show me one repository changeset" use-case.

I have a better suggestion:

Define -rN: to mean -rN:WC
(and symmetrically -r:N to mean -rWC:N).

(This is even a little intuitive ;) since there is no real revision
number that would correspond to the working copy.)

Then Olaf gets his beef (i.e. choosing a consistent default) by defining

    svn diff -rN

to refer only to the N-1:N changes and

    svn diff -rN:

would be the new syntax for the old semantics.

This convention would allow all commands to treat revision intervals in
a consistent fashion while including the working copy as a valid
endpoint.

-- 
Chris Stork (PhD student at UC Irvine)  http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint: B08B 602C C806 C492 D069  021E 41F3 8C8D 50F9 CA2F
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 7 03:45:03 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.