This is the mail archive of the
mailing list for the GCC project.
Re: svn diff branch woprking copy against mainline?
Joe Buck wrote:
On Wed, Nov 02, 2005 at 06:28:42PM -0500, Daniel Berlin wrote:I suggest a search in http://svn.haxx.se/dev/.
On Wed, 2005-11-02 at 14:33 -0800, Mike Stump wrote:
On Nov 2, 2005, at 2:18 PM, Joern RENNECKE wrote:True.
I tried:This works for us:
bash-2.05b$ svn diff Makefile.in svn+ssh://email@example.com/svn/
But that gives me an error message:
svn: Target lists to diff may not contain both working copy paths
svn diff --old svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_4_0_1_release/
gcc/file.c --new file.c
svn needs to go on a long command line diet,
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.
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.
Also, you could
consider stealing some ideas from Perforce, where the command would be
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.
With the above in mind, your p4 example would translate to something
svn diff file.c@branches/gcc_4_0_1_release file.c
(not that this would work, for reasons discussed to death in the
Now suppose your file.c is trunk/somdir/file.c. How is Subversion
supposed to translate from
to the intuitively correct path in the repo, which is
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
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. :)