Re: Merging confuses renamed files

At 10:48 AM -0500 8/22/03, Ben Collins-Sussman wrote:
> * when you 'svn merge' the exact same change to your working copy,
> you *want* to see the intent of the change. It's important to
> see a "D foo, A foo" displayed -- don't cover up this fact by
> displaying "U foo". It's a piece of useful information.
>
>So my proposal is to do the least surprsing thing in each case: 'svn
>diff' should ignore ancestry by default, and 'svn merge' should honor
>ancestry by default. (Of course we'd have switches to allow opposite
>behaviors.)
>
>Any objections to this?

And now (in what may amount to bringing it full circle to John's
original question, if he really was working within one repo, or
thought Subversion really ought to be trans-repo-aware), I'll point
out that in this case, it is a merge going on, and yet it's exactly
the problem that history is being ignored: it's historically known
that Bob's old foo.py and his new bar.py are versions of the same
node. More precisely, since in Subversion (as in Unix) the name of a
file is actually a property of the directory, not of the file itself,
it's historically known that "the directory entry that used to be
named foo.py" on Bob's machine was linked to the same actual file
(node, or possibly even version) as "the directory entry now named
bar.py."

It's worth noting that this is an important difference between files
and directories: like most VC systems, Subversion does not control
the lines of a file, and really has no way to distinguish "change
this line" from "delete this line, add a new one in the same spot."
To do that, Subversion would have to infest the editor, an
unwholesome thought. But Subversion *does* manage the directory
entries, and it *does* know the difference between "rename this file"
and "delete this file, substitute a new one of a different name" (or
even "...substitute a new one of the same name"!). It may well be
that Subversion should behave differently on directories than on
files in this case: no SVN interface need ever say "delete foo; add
foo" if these foos are entries in a directory--unless of course
that's exactly what went on, in which case that's exactly what ought
to be said.

Another interesting difference between files and directories is that
directories have contents of diverse types--that is, files, and other
directories. If "foo" used to be (the name of) a file, and is now
(the name of a different object, which is) a directory, then there
was definitely some "delete/add" stuff going on here! But we don't
have any such idea for the contents of a file: they just contain
"stuff." If Subversion wants to "ignore history" in some diff or
merge context, and that means trying to present this change in a way
that isn't "delete/add," I anticipate some problems somewhere or
other.

-- 
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org