My current thinking is that dir_delta() is not appropriate for "svn diff",
because diff output is about filenames and file contents, not ancestry.
If we ever invent a tree-delta format which contains information about
ancestry (one which can say "copy this old file to this new file and then
apply this diff"), then dir_delta() would become appropriate.
A corollary is that "svn diff" and "svn merge" should not follow the same
algorithm. merge applies a tree delta to the working copy, not a diff.
(So "svn merge" and "svn hypothetical-tree-delta-diff" would follow the
same algorithm.)
On 8 Dec 2002, Philip Martin wrote:
> /repo/dir1/foo.c
> /dir2/foo.c
> /dir3/dir4/foo.c
> 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 would say no. Because diff output is about names and contents, the two
foo.c's should be compared with each other because they have the same
name, even if they have no common ancestry as far as svn knows.
> 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?
Yes. In the second case, foo.c and dir4/foo.c do not have the same name
relative to the base, so you'll see a deletion and addition.
(When you're diffing between two files, the "name relative to the base" is
always the empty string for both files, so is always the same. So it's
always a diff between the contents.)
> I still believe that the current 'svn diff' is correct, and I think
> that 'svn merge' is wrong to allow the merge of the diff between
> arbitrary files without giving at least a warning.
I think users will expect svn diff to obey axioms like "a diff between two
files is always about the relative contents of the files" and "a diff
between two directories whose contents are identical is always empty."
> I think that, in general, if you attempt to merge unrelated files you
> are doing something wrong.
It suggests you're not using the version control system to its full
potential, but it doesn't mean the version control system should fight
you.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 8 22:42:48 2002