Ben Collins-Sussman <sussman@collab.net> writes:
> Mmm, yah. Crud. If someone really replaced a file, and you're
> merging that change into your working copy, then this is the
> difference between ending up with an 'M' versus an 'A +'. This is
> about the only case where the working copy actually tracks ancestry.
The other example where detecting relatedness is nice was with diff
(not merge):
If two files are not related, then showing a diff between their
contents is a bit misleading. The contents are unrelated, so the diff
between them will be random. It's more useful to the user to show all
of one file, then all of the other, than to show a random diff.
Now, you might think that if the contents of A and B are truly
unrelated, then if you run "diff A B", you'll automatically get the
desired result: all the contents of one file, followed all the
contents of the other (never mind which is prefixed by "-" and which
by "+"; the user can mentally filter that part out).
To test this theory, I ran both
$ diff A B
$ diff -u A B
where A is the contents of this email message up to the end of the
next line, and B is the United States Constitution.
Turns out the diff hunks are interleaved; you don't get all of one
file followed by all of the other.
On the other hand, in conversation just now with Ben and Mike, they
seemed pretty certain that this is an edge case, plus there's the "if
you're diffing two unrelated files, you get what you deserve" factor
:-).
I dunno. I guess I think "adding more switches and knobs" is actually
a good solution here. Specifically, this switch is the one you flip
when some data is missing from your repository -- data about shared
ancestry. As Philip pointed out, if the vendor branch imports had
been done right in the first place, dir_deltas() would behave fine.
So this proposal is really about not punishing people whose vendor
branch imports, for whatever reason, were *not* done right.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 9 20:48:29 2002