Philip Martin <philip@codematters.co.uk> writes:
> > --- a (revision 1532)
> > +++ b (revision 1532)
> > @@ -0,0 +1,2 @@
> > -hi
> > +hi
> > +bye
>
> Really? I was not aware that svn diff ever did this for unrelated
> files.
I was confused. The output of svn diff has never changed.
Using two different filenames a and b confused me. Here is what
i actually saw in the past and still see today:
% svn diff http://pretzelnet.org/svn/tmp/{1,2}/foo
Index: foo
===================================================================
--- foo (revision 1533)
+++ foo (revision 1533)
@@ -1 +0,0 @@
-hi
Index: foo
===================================================================
--- foo (revision 1533)
+++ foo (revision 1533)
@@ -0,0 +1,2 @@
+hi
+bye
Same as today. And if i apply that patch to a foo file
containing only the single 'hi' line, it does indeed transform
it into the second form (two lines, 'hi' and 'bye'). But my
point still stands. Try this:
svn diff http://pretzelnet.org/svn/tmp/{1,2}/gnuserv.c
svn diff http://pretzelnet.org/imports/gnuserv/base/gnuserv.c \
http://pretzelnet.org/misc/gnuserv/gnuserv.c
The resulting diff from each command does the same thing when
fed to patch (i.e. transform gnuserv.c as it exists in the first
form to how it exists in the second form) whether the files
share ancestry or not. The issue is that one of the diffs is
human-readable while the other is not.
> Not good. If you want to propose changes in behaviour it is better to
> understand the current behaviour.
While i did have a slight misunderstanding, i hope what i say
above illustrates that my point still stands.
> It does work, it just doesn't work the way you assumed it would.
No, i never had any doubt that the resulting diff works when fed
to patch. The issue is that one diff is a useless pile of
removing all lines of the first form followed by adding all lines
of the second, but the other diff is a meaningful diff.
> simple. Making it work the way you would prefer would involve more
> work, more special cases and more code. It would in fact be making
> svn diff "smart", the very crime of which you have accused it.
What? Not at all. The current problem is svn is doing
something itself (i don't know what exactly). If it just handed
the two arguments to diff(1), the diff would come out meaningful.
When i diff two branches in cvs, i get the same diff i'd get if
i checked out both branches and ran diff -r on the two
directories. My argument is that svn perhaps ought to do the
same thing.
> If you are comparing files that do not have a common ancestor then you
> are doing something wrong as far as a version control system is
> concerned. While it is legitimate to compare arbitrary files in a
> general, non-version controlled fashion, I'm not sure that we need
> Subversion to do it.
You may have a point here. It is possible that this issue is
blown up in importance in my mind only because import's
uselessness cause me great pain trying to figure out how to
implement vendor branches. However, *my* gut reaction is that
svn diff is still trying to be too smart.
--
Eric Gillespie <*> epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 7 16:53:56 2002