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

New diff syntax? (see issue #1142)

From: <kfogel_at_collab.net>
Date: 2003-05-15 22:59:25 CEST

[I vaguely recall that this is not the first time this topic has come
up on the list, I just don't remember previous threads coming to a
definite conclusion.]

In issue #1142, Brandon Ehle said:

> Although you can run svn diff on wc item vs another revision in
> the same branch, or items in two different branches, there is no
> way to diff a wc item vs a revision of that item in a branch.
>
> This is an extremely important feature for doing vendor branch
> merges.

Mike and I just reread that issue, and realized that Brandon's point
is that the command-line syntax 'svn diff' doesn't even allow one to
express this meaning.

Instead, 'svn diff' works in a way that causes a lot of confusion
(judging from the list traffic), because it is highly optimized for
comparing the local file against its base text. If you give it these
two arguments, for example:

   $ svn diff foo http://svn.blah.com/repos/branches/mybranch/foo

you might expect this to diff your local `foo' against the branch
version. But it doesn't do that. Instead, it attempts *two* diffs:

   (1) working `foo' against text-base `foo'
   (2) working `http://...' against text-base `http://...'

Of course, the second diff fails, since there is no such file. If you
were to invoke it on three local files and two URLs, you'd simply get
three successes and two failures.

Here's what the error looks like:

   $ svn diff README \
              http://svn.collab.net/repos/svn/branches/cvs2svn-kfogel/README
   Index: README
   ===================================================================
   --- README (revision 5950)
   +++ README (working copy)
   @@ -4,6 +4,7 @@
    
    $LastChangedDate$
    
   +(I added this line to my local copy of README)
    Contents:
    
         I. A FEW POINTERS
   subversion/libsvn_client/diff.c:1156: (apr_err=200004)
   svn: Incorrect parameters given
   svn: Sorry, svn_client_diff was called in a way that is not yet supported.
   subversion/libsvn_client/diff.c:1204: (apr_err=200004)
   svn: do_diff: path isn't a working-copy path.

(Boy, sure would be nice if that last error printed out the argument,
wouldn't it! We should fix that no matter what).

To solve this problem, I think we need to change the 'svn diff'
syntax. Mike Pilato proposed there be two ways to invoke it:

   $ svn diff [-rN] [ARG]

     Diffs working file ARG against its text-base, or if -r is given,
     diffs against revision N instead of the base revision. If no ARG
     is given, then diff behaves as it does currently when invoked on
     `.' .

and

   $ svn diff [-rN[:M]] ARG1 ARG2

always diffs ARG1 against ARG2, no matter what combination of local
files or URLs they are. N and M apply to ARG1 and ARG2 respectively;
you can always omit one or use the `WORKING' keyword if necessary.

So 'svn diff' would now take either one argument, or two, no more than
that. If you want to get diffs for a specific list of files, you just
invoke 'svn diff' on each file individually. Which is fine: as Mike
points out, 'patch' handles concatenated diff output transparently.
Bonus: the output of 'svn help diff' becomes a lot easier to
understand. (Whether we keep the "file@REV" syntax is a separate
question, and I'd like to keep that bikeshed out of this thread).

We're both +1 on this new syntax, but want some feedback. Personally,
I always run 'svn diff' either on one file, or with no arguments at
all. I never run it on, say, three files :-). I probably *would* run
it to compare against URLs if I could...

But hey, anecdotal evidence is just anecdotal evidence.

How do people feel about this change?

-Karl (& Mike by proxy)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 15 23:43:36 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.