Philip Martin <email@example.com> writes:
> I not sure what "diff(1) in all cases" means. All 'svn diff' output
> is produced by running diff(1).
Apparently it isn't. Look at all the examples i've provided.
Diffing a and b with diff(1) produces a meaningful diff.
Diffing the two gnuserv.c versions with diff(1) or diffing with
svn when they share ancestry produces the meaningful diff,
diffing with svn they *don't* share ancestry produces a useless
diff. If as you claim it simply passed off the files to
diff(1), that would not be the case.
> svn diff http://host/repo/dir1/foo.c http://host/repo/dir2/foo.c
> svn diff http://host/repo/dir1/foo.c http://host/repo/dir3/dir4/foo.c
> to ignore revision history and generate direct file-to-file diff. Now
> suppose I run
> svn diff http://host/repo/dir1 http://host/repo/dir2
> That will produce a different diff for foo.c than that produced by the
> command run on foo.c directly. I think it is "obviously" wrong for
> the form of the diff to depend on the URL in this way. That's also
> why I think the merge behaviour is wrong.
> Or does you request for "diff(1) in all cases" mean that you want the
> directory diff command to ignore revision history as well? I don't
> know how that would be implemented.
Then you aren't listening. If svn would simply hand off the
files to diff(1) *regardless* of whether they're files, or
directories, or widgets, you'd get meaningful results where
possible or equally useless results where not.
To prove this to yourself, just do a svn export of any two URLs
you are curious about and diff -r the two resulting directories.
> svn diff http://host/repo/dir1 http://host/repo/dir3/dir4
> svn diff http://host/repo/dir1 http://host/repo/dir3
> Would they show different diffs for foo.c?
Eric Gillespie <*> firstname.lastname@example.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: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sun Dec 8 17:15:58 2002