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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]/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
[EMAIL PROTECTED] 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 [EMAIL PROTECTED] .
(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.
