Re: svn diff branch woprking copy against mainline?

[Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>]

Branko Äibej wrote:
> 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.

But it could know that gcc-checkout/ was checked out from trunk, so 
gcc-checkout/gcc was checked out from the gcc subdirectory of trunk.

More formally, you can say that any file in the checkout is made of 
BASE/DIR/filename where BASE is the URL passed to the latest `svn co' or 
`svn switch' command. If filename is BASE/DIR/filename, filename@BRANCH 
could be BRANCH/DIR/filename.

I guess this would require adding an attribute to the <entry kind="dir"> 
tag of the entries file, a la

<entry
   committed-rev="106385"
   name=""
   committed-date="2005-11-02T15:33:18.398776Z"
   url="svn://gcc.gnu.org/svn/gcc/branches/dataflow-branch/gcc"
>> base="svn://gcc.gnu.org/svn/gcc/branches/dataflow-branch"     <<<<<
   last-author="dberlin"
   kind="dir"
   uuid="138bc75d-0d04-0410-961f-82ee72b054a4"
   repos="svn+ssh://bonzini@gcc.gnu.org/svn/gcc"
   prop-time="2005-10-28T21:45:00.000000Z"
   revision="106422"/>


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

Ehm, I guess you're right...

Paolo