Re: svn diff branch woprking copy against mainline?

[Branko Äibej <brane at xbc dot nu>]

Joe Buck wrote:
> On Wed, Nov 02, 2005 at 06:28:42PM -0500, Daniel Berlin wrote:
>   
> > On Wed, 2005-11-02 at 14:33 -0800, Mike Stump wrote:
> >     
> > > On Nov 2, 2005, at 2:18 PM, Joern RENNECKE wrote:
> > >       
> > > > I tried:
> > > > bash-2.05b$ svn diff Makefile.in svn+ssh://amylaar@gcc.gnu.org/svn/ 
> > > > gcc/trunk/gcc/Makefile.in@106390
> > > >
> > > > But that gives me an error message:
> > > >
> > > > svn: Target lists to diff may not contain both working copy paths  
> > > > and URLs
> > > >         
> > > This works for us:
> > >
> > > svn diff --old svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_4_0_1_release/ 
> > > gcc/file.c --new file.c
> > >
> > > for example.
> > >
> > > svn needs to go on a long command line diet, 
> > >       
> > True.
> > However, it *does* need some way to differentiate between url->url,
> > url->wc, and wc->url commands, so even if there was an SVNROOT, you'd
> > still have to specify it  on the command lines :)
> >     
>
> It certainly seems that --old and --new are redundant.
I suggest a search in http://svn.haxx.se/dev/.

> Also, you could
> consider stealing some ideas from Perforce, where the command would be
> something like
>
> p4 diff file.c@gcc_4_0_1_release file.c
>
> and the RCS figures out how to map the label to the repository version.
> Basically, the # and @ characters are special; # is used to introduce
> a revision number (the global revision number), and a number of things
> can follow @, like a label, or a date.
>   
This seems to be a common misconception. The important thing to remember 
here is that there is no separate namespace for labels and branches in 
SVN, and that the layout of the repository is arbitrary. IOW, the fact 
that you have branches in /branches is a convention, not something 
imposed by the SVN server.

With the above in mind, your p4 example would translate to something 
like this:

   svn diff file.c@branches/gcc_4_0_1_release file.c

(not that this would work, for reasons discussed to death in the 
dev@subversion archives).

Now suppose your file.c is trunk/somdir/file.c. How is Subversion 
supposed to translate from

    trunk/somedir/file.c@branches/gcc_4_0_1_release

to the intuitively correct path in the repo, which is

   branches/gcc_4_0_1_release/somedir/file.c ?

It can't, because it doesn't know that trunk is special.


Now, as of not too long ago we can teach the svn client to expand the 
repository root; your example would become (assuming your working copy 
is on trunk, and assuming % expands to the repos root):

   svn diff --old %/branches/gcc_4_0_1_release/somedir/file.c --new file.c

I suppose that's a bit better, although I admit it's not ideal.



However, before coming up with a zillion suggestions about how to make 
the syntax nicer, please do consider the idea that we did put a lot of 
thought into the diff syntax, and that covering all the uses and edge 
cases and is not easy. I'll be the first to admit that the current 
syntax sucks, but it works -- as opposed to most proposed (and many once 
implemented, now defunct...) forms that usually break down in the most 
trivial cases.

Telling the SVN devs to "change the diff syntax like /this/" is a bit 
like telling the GCC devs to "just add this extension to g++". We all 
know what the response to /that/ usually is. :)

-- Brane