You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2003/05/15 20:59:25 UTC

New diff syntax? (see issue #1142)

[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

Re: New diff syntax? (see issue #1142)

Posted by Ben Collins-Sussman <su...@collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:

> I really would like to know if the reason for the change is because
> people changed their minds or because a different group of people
> could be bothered to speak up.  Was it experience with the old
> interface?  Were the arguments more convincing this time?

I implemented the first UI for 'svn diff'.  It was a messy problem,
and cmpilato, kfogel and I designed the UI on a whiteboard.  A driving
force behind the original UI was kfogel's insistence that

   svn diff tgt1 tgt2 tgt3 tgt4 ...

...be the "primary" use case, used to display local mods on a long
list of targets.  This was modeled after the CVS UI.

I honestly don't remember the arguments on the list that ensued after
that.  :-(

But I think there were many reasons that made us want to backtrack and
change the interface:

  1. kfogel, my, and other's realization that in practice, that
     "primary use case" didn't seem to be so common.  (I, for one,
     just run 'svn diff' on entire directories.)

  2. noticing that many newbies repeatedly expect 'svn diff foo.c
     bar.c' to diff the two objects.  It's a constant source of
     confusion.

  3. noticing that the current UI makes it impossible to diff an
     arbitrary wc file against an arbitrary repos file (issue #1142)

Philip, if you made these arguments a year ago, then I think we owe
you an apology.  Perhaps we needed a big head-whack of empiricism
before seeing the light.  :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by Philip Martin <ph...@codematters.co.uk>.
cmpilato@collab.net writes:

> > Philip Martin <ph...@codematters.co.uk> writes:
> > > I proposed dropping the "iterative" diff last year, and I seem to
> > > remember that I got little support for it.
> 
> Sorry if this turn of events leaves you sour, Philip.

I'm not sour at all--it's going to work the way I think it should work
and I didn't have to code it :)

I really am interested in the procedure we use to evaluate ideas like
this.  The outcome was different last time, does this mean that if we
were to ask again six months from now we would get a different answer?
I really would like to know if the reason for the change is because
people changed their minds or because a different group of people
could be bothered to speak up.  Was it experience with the old
interface?  Were the arguments more convincing this time?

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by cm...@collab.net.
kfogel@collab.net writes:

> Philip Martin <ph...@codematters.co.uk> writes:
> > I proposed dropping the "iterative" diff last year, and I seem to
> > remember that I got little support for it.  It appears to be different
> > now--does this mean that people have changed their minds, or that they
> > didn't get involved in the previous discussion, or that they were not
> > around last year or what?
> 
> In my case, it means I changed my mind (after seeing more list
> feedback).

Sorry if this turn of events leaves you sour, Philip.  I imagine we'll
suffer plenty more of these inabilities to recognize genius the first
time 'round in the future.  :-)

Regardless, the new syntax has been coded (did it on the train ride
home).  Running tests now (and then will follow with some
hand-testing).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by kf...@collab.net.
Philip Martin <ph...@codematters.co.uk> writes:
> I proposed dropping the "iterative" diff last year, and I seem to
> remember that I got little support for it.  It appears to be different
> now--does this mean that people have changed their minds, or that they
> didn't get involved in the previous discussion, or that they were not
> around last year or what?

In my case, it means I changed my mind (after seeing more list
feedback).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by Philip Martin <ph...@codematters.co.uk>.
kfogel@collab.net writes:

> 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.

I proposed dropping the "iterative" diff last year, and I seem to
remember that I got little support for it.  It appears to be different
now--does this mean that people have changed their minds, or that they
didn't get involved in the previous discussion, or that they were not
around last year or what?

[I am still in favour, I just wondering if we are about to implement
something that will be very unpopular.]

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by marvin greenberg <ma...@acm.org>.
> 
> How do people feel about this change?
> 
+1 

Marvin
(with a secret oops)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by kf...@collab.net.
Robert Pluim <rp...@bigfoot.com> writes:
> Why only one revision?  Sometimes I want to see what changed between
> two revisions, neither of which is my base, and I expect to be able to
> type eg

Sorry, just a typo on my part.  But it looks like we hashed this all
out before, and Greg Hudson came up with a solution; I've annotated
the issue.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by Robert Pluim <rp...@bigfoot.com>.
kfogel@collab.net writes:

[snip description of current syntax]

 > 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
 >      `.' .

Why only one revision?  Sometimes I want to see what changed between
two revisions, neither of which is my base, and I expect to be able to
type eg

$ svn diff -r3:4 README

 > 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.
 >

Oh, OK, so I could type

$ svn diff -r3:4 README README

but that seems excessive :-)

 > 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).
 >

:-) OK.  I have definite opinions on that one, which we can talk about
some other time.

 > 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?

+1, the current svn diff syntax is too confusing, and this one is much
better.


Robert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2003-05-15 at 18:06, Greg Hudson wrote:
> There was the "smart" proposal and the "dumb" proposal; the "dumb"
> proprosal was genuinely pretty dumb and should never have received any
> consideration.  But I believe there was consensus at that time on the
> "smart" proposal

... but there doesn't appear to be consensus on it now.  Well, I use the
iterative case in CVS with some frequency, but I can live without it, so
if people like Karl's proposal, that's okay with me.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> There was the "smart" proposal and the "dumb" proposal; the "dumb"
> proprosal was genuinely pretty dumb and should never have received any
> consideration.  But I believe there was consensus at that time on the
> "smart" proposal, which was:
>         
>           Iterative case:    svn diff [-r {N|N:M}] TARGET ...
>           Comparative case:  svn diff TARGET TARGET
>         
>         In the comparative case, TARGET can be URL@REV as well as
>         just URL or WCPATH, of course.  To resolve the ambiguous
>         case where two targets are specified and no -r option is given:
>         
>           If both targets are wc paths, assume iterative case.
>           Otherwise, assume comparative case.

Ah, yes, it's all coming back to me, now.  Thanks.

I'm okay with it.  It's one of those cases where inconsistency may
actually be more intuitive (the ambiguity resolution algorithm, I
mean).

I'd like to name this as the solution to issue #1142 (though we won't
be able to get it into this milestone).  Since we appear to have
consensed on this solution already, I'll just add it to the issue and
put it in 0.24 or 0.25.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by Robert Pluim <rp...@bigfoot.com>.
Michael Wood writes:
 > On Fri, May 16, 2003 at 01:59:20AM +0200, Robert Pluim wrote:
 > > cmpilato@collab.net writes:
 > >  > -0.99.  This kind of "document around the edge case" is bound to bite
 > >  > us.  The minute we make this change, someone's going to complain about
 > >  > how they tried to run 'svn diff trunk/foo tags/0.14/foo' and didn't
 > >  > see what they expected.
 > >  >
 > > 
 > > Personally, I'd be quite happy if that showed me the differences
 > > between trunk/foo and tags/0.14/foo.  What do you think the
 > > expectation would be?
 > [snip]
 > 
 > That's exactly the point he was trying to make.  The "smart" proposal
 > would have meant:
 > 
 > 	$ svn diff trunk/foo tags/0.14/foo
 > 
 > would be equivalent to:
 > 
 > 	$ diff -u trunk/.svn/text-base/foo.svn-base trunk/foo; \
 > 	  diff -u tags/0.14/.svn/text-base/foo.svn-base tags/0.14/foo
 > 
 > (unless I misunderstood this part of the smart proposal.)

Hmm, I think that means I misunderstood that part then.  (Looks
again).  Yep.  OK, I agree with Mike, the iterative case is EEEEEVIL,
lets junk it. (thinking back, I've only ever used the iterative case
by accident when I meant something else anyway)

Robert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by Michael Wood <mw...@its.uct.ac.za>.
On Fri, May 16, 2003 at 01:59:20AM +0200, Robert Pluim wrote:
> cmpilato@collab.net writes:
>  > -0.99.  This kind of "document around the edge case" is bound to bite
>  > us.  The minute we make this change, someone's going to complain about
>  > how they tried to run 'svn diff trunk/foo tags/0.14/foo' and didn't
>  > see what they expected.
>  >
> 
> Personally, I'd be quite happy if that showed me the differences
> between trunk/foo and tags/0.14/foo.  What do you think the
> expectation would be?
[snip]

That's exactly the point he was trying to make.  The "smart" proposal
would have meant:

	$ svn diff trunk/foo tags/0.14/foo

would be equivalent to:

	$ diff -u trunk/.svn/text-base/foo.svn-base trunk/foo; \
	  diff -u tags/0.14/.svn/text-base/foo.svn-base tags/0.14/foo

(unless I misunderstood this part of the smart proposal.)

-- 
Michael Wood <mw...@its.uct.ac.za>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by Robert Pluim <rp...@bigfoot.com>.
cmpilato@collab.net writes:
 > -0.99.  This kind of "document around the edge case" is bound to bite
 > us.  The minute we make this change, someone's going to complain about
 > how they tried to run 'svn diff trunk/foo tags/0.14/foo' and didn't
 > see what they expected.
 >

Personally, I'd be quite happy if that showed me the differences
between trunk/foo and tags/0.14/foo.  What do you think the
expectation would be?

 > That said, I see the benefit of having an iterative case.

The problem to me is the iterative case which svn diff does now with
more than one target.  I think the normal mode of diff should be
comparative.

Robert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by Branko Čibej <br...@xbc.nu>.
cmpilato@collab.net wrote:

>"Sander Striker" <st...@apache.org> writes:
>  
>
>>In conclusion, -0 on the "smart" proposal, +1 on the previous
>>kfogel/cmpilato proposal.  All IMHO.
>>    
>>
>
>Let's be honest here.  How humble, exactly, are any of our opinions? ;-)
>  
>

Immensely humble, young man, and I'm giving this a +1, so get on the
ball and start implementing it!

You owe the Oracle a smiley

-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by cm...@collab.net.
"Sander Striker" <st...@apache.org> writes:

> > That said, I see the benefit of having an iterative case.  Maybe the
> > thing to do here is to spawn a new subcommand:
> > 
> >    svn diff [TARGET [TARGET ...]]   - hits the most common use-case,
> >                                       iterative, showing local mods only.
> > 
> >    svn compare TARGET1[@REV1] TARGET[@REV2]  - takes care of the
> >                                                comparative case.
> 
> Ewww.  Just forget about the iterative case.  Being used to running
> diff (yes, diff, not svn diff), I expect, that when provided
> two targets, those will be compared.  I mean, when have you last
> tried "diff X Y Z P ..." ?

You don't have to convince me!  :-)

> In conclusion, -0 on the "smart" proposal, +1 on the previous
> kfogel/cmpilato proposal.  All IMHO.

Let's be honest here.  How humble, exactly, are any of our opinions? ;-)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

RE: New diff syntax? (see issue #1142)

Posted by Sander Striker <st...@apache.org>.
> From: cmpilato@collab.net [mailto:cmpilato@collab.net]
> Sent: Friday, May 16, 2003 1:41 AM

> Greg Hudson <gh...@MIT.EDU> writes:
> 
> > Long, long ago, I raised two proposals for the svn diff syntax.  See:
> > <http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=14290>.  
> > 
> > There was the "smart" proposal and the "dumb" proposal; the "dumb"
> > proprosal was genuinely pretty dumb and should never have received any
> > consideration.  But I believe there was consensus at that time on the
> > "smart" proposal, which was:
> >         
> >           Iterative case:    svn diff [-r {N|N:M}] TARGET ...
> >           Comparative case:  svn diff TARGET TARGET
> >         
> >         In the comparative case, TARGET can be URL@REV as well as just URL or
> >         WCPATH, of course.  To resolve the ambiguous case where two targets
> >         are specified and no -r option is given:
> >         
> >           If both targets are wc paths, assume iterative case.
> >           Otherwise, assume comparative case.
> 
> -0.99.  This kind of "document around the edge case" is bound to bite
> us.  The minute we make this change, someone's going to complain about
> how they tried to run 'svn diff trunk/foo tags/0.14/foo' and didn't
> see what they expected.
> 
> That said, I see the benefit of having an iterative case.  Maybe the
> thing to do here is to spawn a new subcommand:
> 
>    svn diff [TARGET [TARGET ...]]   - hits the most common use-case,
>                                       iterative, showing local mods only.
> 
>    svn compare TARGET1[@REV1] TARGET[@REV2]  - takes care of the
>                                                comparative case.

Ewww.  Just forget about the iterative case.  Being used to running
diff (yes, diff, not svn diff), I expect, that when provided
two targets, those will be compared.  I mean, when have you last
tried "diff X Y Z P ..." ?

We give the user a nice extra in the form of one target, which
shows the local changes to his wc, or when passed specific revs, a
diff between those revs.

In conclusion, -0 on the "smart" proposal, +1 on the previous kfogel/cmpilato
proposal.  All IMHO.


Sander

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by cm...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:

> Long, long ago, I raised two proposals for the svn diff syntax.  See:
> <http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=14290>.  
> 
> There was the "smart" proposal and the "dumb" proposal; the "dumb"
> proprosal was genuinely pretty dumb and should never have received any
> consideration.  But I believe there was consensus at that time on the
> "smart" proposal, which was:
>         
>           Iterative case:    svn diff [-r {N|N:M}] TARGET ...
>           Comparative case:  svn diff TARGET TARGET
>         
>         In the comparative case, TARGET can be URL@REV as well as just URL or
>         WCPATH, of course.  To resolve the ambiguous case where two targets
>         are specified and no -r option is given:
>         
>           If both targets are wc paths, assume iterative case.
>           Otherwise, assume comparative case.

-0.99.  This kind of "document around the edge case" is bound to bite
us.  The minute we make this change, someone's going to complain about
how they tried to run 'svn diff trunk/foo tags/0.14/foo' and didn't
see what they expected.

That said, I see the benefit of having an iterative case.  Maybe the
thing to do here is to spawn a new subcommand:

   svn diff [TARGET [TARGET ...]]   - hits the most common use-case,
                                      iterative, showing local mods only.

   svn compare TARGET1[@REV1] TARGET[@REV2]  - takes care of the
                                               comparative case.
    

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by Greg Hudson <gh...@MIT.EDU>.
Long, long ago, I raised two proposals for the svn diff syntax.  See:
<http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=14290>.  

There was the "smart" proposal and the "dumb" proposal; the "dumb"
proprosal was genuinely pretty dumb and should never have received any
consideration.  But I believe there was consensus at that time on the
"smart" proposal, which was:
        
          Iterative case:    svn diff [-r {N|N:M}] TARGET ...
          Comparative case:  svn diff TARGET TARGET
        
        In the comparative case, TARGET can be URL@REV as well as just URL or
        WCPATH, of course.  To resolve the ambiguous case where two targets
        are specified and no -r option is given:
        
          If both targets are wc paths, assume iterative case.
          Otherwise, assume comparative case.
        
However, nobody ever implemented it.  Certainly, some people suggested
your idea at that time, but several people were unhappy with the idea of
eliminating the iterative case.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by kf...@collab.net.
Benjamin Pflugmann <be...@pflugmann.de> writes:
> With CVS? Sorry, if I wasn't clear, I meant CVS when talking that part.

Oh, no, I meant with Subversion.  (But in any case, the comparitive
behavior you get with CVS and two revisions is subtly different from
that which you'd get from Subversion's anyway, so I'm not sure the two
cases are comparable).

> Hm. To clarify, I don't worry that much about understanding the error
> than achieve what was intended? I think that part would be irritating.
> I, at least, have not yet figured out how I would accomplish the same
> as with "svn diff *.h", except for running "ls *.h | xargs -n1 svn diff".

Right -- you'd just have to find a way to run 'svn diff' multiple
times.  "This is the new normalcy", as Dick Cheney famously said.  

You gotta problem with that? :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by Benjamin Pflugmann <be...@pflugmann.de>.
On Fri 2003-05-16 at 15:25:21 -0500, kfogel@collab.net wrote:
> Benjamin Pflugmann <be...@pflugmann.de> writes:
> > Please correct me, if I am wrong, but considering that CVS's default
> > usage is the iterative one (if I understand it correctly, you get the
> > comparitative usage only when you specify two revision numbers), don't
> > you think that this will irritate CVS converts?
> 
> No, you don't need -r to get comparative behavior -- just specifying
> two args is enough.

With CVS? Sorry, if I wasn't clear, I meant CVS when talking that part.

> Otherwise, that summary seems correct.  I don't know if it will
> irritate CVS users or not.  (We need to make sure to error clearly on
> N>2 args, though.)

Hm. To clarify, I don't worry that much about understanding the error
than achieve what was intended? I think that part would be irritating.
I, at least, have not yet figured out how I would accomplish the same
as with "svn diff *.h", except for running "ls *.h | xargs -n1 svn diff".

     Benjamin.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by kf...@collab.net.
Benjamin Pflugmann <be...@pflugmann.de> writes:
> Please correct me, if I am wrong, but considering that CVS's default
> usage is the iterative one (if I understand it correctly, you get the
> comparitative usage only when you specify two revision numbers), don't
> you think that this will irritate CVS converts?

No, you don't need -r to get comparative behavior -- just specifying
two args is enough.

Otherwise, that summary seems correct.  I don't know if it will
irritate CVS users or not.  (We need to make sure to error clearly on
N>2 args, though.)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by Benjamin Pflugmann <be...@pflugmann.de>.
On Fri 2003-05-16 at 12:57:14 -0500, kfogel@collab.net wrote:
> Brian Denny <br...@briandenny.net> writes:
> > +1 on the new kfogel/cmpilato proposal,
> > -0 on the 'old consensus'
> > 
> > ...for reasons already well articulated by others in this thread.
> 
> Okay, my sense is that there *is* a consensus for the new
> cmpilato/kfogel proposal (which gets rid of the iterative case
> entirely), but not for Greg Hudson's earlier proposal.

Do I understand correctly, that

  $ svn diff *.h

wouldn't work anymore?

Please correct me, if I am wrong, but considering that CVS's default
usage is the iterative one (if I understand it correctly, you get the
comparitative usage only when you specify two revision numbers), don't
you think that this will irritate CVS converts?

Again, I am not strongly for/against it (I like the simplification,
but will miss the use case above), but just wanted to make sure the
implications are understood (okay, honestly, that *I* understand
them ;-).

    Benjamin.





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by kf...@collab.net.
Brian Denny <br...@briandenny.net> writes:
> +1 on the new kfogel/cmpilato proposal,
> -0 on the 'old consensus'
> 
> ...for reasons already well articulated by others in this thread.

Okay, my sense is that there *is* a consensus for the new
cmpilato/kfogel proposal (which gets rid of the iterative case
entirely), but not for Greg Hudson's earlier proposal.

I'll point to this thread in the issue, and describe the proposal
there.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New diff syntax? (see issue #1142)

Posted by Brian Denny <br...@briandenny.net>.

+1 on the new kfogel/cmpilato proposal,
-0 on the 'old consensus'

...for reasons already well articulated by others in this thread.

-brian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

RE: New diff syntax? (see issue #1142)

Posted by Sander Striker <st...@apache.org>.
> From: kfogel@collab.net [mailto:kfogel@collab.net]
> Sent: Thursday, May 15, 2003 10:59 PM

> How do people feel about this change?

+1.  A lot more intuitive.


Sander

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

RE: New diff syntax? (see issue #1142)

Posted by Mark Watts <mw...@stny.rr.com>.
> From: kfogel@collab.net [mailto:kfogel@collab.net] 
But hey, anecdotal evidence is just anecdotal evidence.
> 
> How do people feel about this change?
> 

+1

Being new to SVN, I can attest that the current options are very confusing.

-Mark



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org