Re: svn diff branch woprking copy against mainline?

[Joern RENNECKE <joern dot rennecke at st dot com>]

Branko Äibej wrote:

>  
>
> > It certainly seems that --old and --new are redundant.
>
> I suggest a search in http://svn.haxx.se/dev/.

What should we search for?  I tried both of --old and --new, and both 
searches
came up empty.

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

It's not a misconception, it's a perception of an svn shortcoming.  
There should be a configurable mapping from branch/tag names to branch/tag
locations.  I.e. you tell the svn server once what your conventions are, 
and then you don't have to apply them by hand every time you refer to
a branch or tag.  Without such a mechanism, svn makes a rather poor cvs 
replacement.

> 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

This syntax is bad not only because of the need to mention branches/ but 
also because you need to name file.c twice.
And how would you expand it to diff several files against a different 
branch/tag?

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

url(s), please.

[translating branch->location]

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

Yes, that's one of the things that we have to tell it in some config 
file.  I think it's ok if we consider
'trunk' aka 'mainline' a branch/tag at the location trunk/ .  I.e. to 
diff a branch working copy
against the current mainline, you could say -rtrunk; to diff it against 
yesterdays mainline,
-rtrunk -Dyesterday or -rtrunk@106373 .

(There is a remaining disadvantage here against cvs because we can't any 
longer use a single
version number to refer to a particular version in a particular 
branch.  However, that only
really applies to single files; for multiple files, in cvs you'd have 
to use dates or symbolic
tags to refer to a particular state of mainline/a branch ).

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

Actually, it's not only diff.  Being able to refer to tags/branches by 
name is also important for other operations like log, annotate (aka 
blame), update,
merge...
I get the impression that a lot of work has gone into designing the 
underlying repository, and that is certainly fundamental to having
a powerful version control system, but the usability of the command-line 
interface is still way behind cvs when you want to seriously
work with branches.

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

It's a bit different here because we had something that worked for us 
before - cvs.  The main lure of switching to svn has been the promise of
better performance when doing operations on branches, and keeping 
history across copy / rename operations.  If working on branches turns
out to be actually harder with svn because it has no clue where the 
branches are, we might be better off with cvs after all.

More to the point, if I understood Daniel Berlin correctly, he offered 
to do some work on subversion to make it fit the requirements of the gcc
project.  But before any such work with regards to naming tags/branches 
can be done, there should be a consensus from the gcc developers about
what it is we want, and buy-in from the svn developers that the design 
would be acceptable for svn.

Thus, it is important that we have this discussion about design first.

In general, a repository could have more than one project, and 
branches/tags for one project need to apply to another one.  E.g.
if binutils and gdb switch, they might want to the same loction as 
'trunk' but keep branches in different places, and occasionally
use identical branch names (which refer to different locations).  There 
is also the isssue that not all files in the repository
belong to each project, yet they share enough files that trying to split 
them entirely apart is not really well maintainable.
So, it seems  that long-term, svn needs something along the lines of cvs 
modules files which list per-project what  directories  / files
actually belong to them.  Since the information about  how branch names 
and location correspond is also per-project, it appears
natural to me to combine these two.  AFAICT we don't urgently need the 
modules capability for gcc.  It would be useful, though, to
define subsets that people can check out if there are only interested in 
a subset of the languages.
Therefore, I think we should design a configuration file layout that can 
express both branch/tag name->location mappings and modules,
but with an eye to only implement the former initially.

I am sure a lot of people have had bad experiences with the modules 
file.  However, AFAICT the problem is not with the
concept of the modules file, but that the versioning was incorrectly 
applied.  In CVS, you always use the current modules
file, even when you check out a very old branch.  This leads to problems 
when files are added to / removed from a module,
which then affects retroactively what you'll check out from the old 
branch.  Usually, these retroactive changes only lead to
problems, since using old branches/tags no longer checks out the same 
code base as it used to.   The only time this made sense
was when the repository itself was modified from the outside, i.e. 
changing directories and/or file names around.  This
should not happen with subversion in the first place, since directories 
are versioned, and there are svn operations to move
directories; old revisions still refer to the old source tree 
structure.  Thus, the modules should be versioned along with the
sources that they refer to.  I.e. the actual modules file with the list 
of files and directories belonging to the module belongs
into the root directory location of a trunk/branch/tag.  On the other 
hand, we'd like to be able to specify a module name and
a trunk/branch/tag name for a checkout.  Thus, we need a 
repository-global index that maps module names to projects, and
for each project, map trunk/branch/tag names to locations.