Re: Merging confuses renamed files

At 1:26 PM -0500 8/22/03, Ben Collins-Sussman wrote:
>Can you be more specific? What's inconsistent? Why *specifically* is
>the inconsistency confusing?

As I said, the most compelling confusion I have is, "what on earth
does your speculation about my expectations actually suggest?" I'm
not saying you end up with the wrong answer, I'm saying there is no
inference there. There is, however, another basis for more reliably
deriving expectation, because these things "diff" and "merge" have
been going on for ages before SVN was ever thunk.

>Are you arguing that if I run
>
> $ svn diff URL1 URL2
>
> ... and see a true diff on 'foo', that I will surprised and
> confused when I then run
>
> $ svn merge URL1 URL2 .
> D foo
> A foo
>
> ... and see the delete + add, rather than "U foo" ?

In another message, I pointed out SVN's opportunity to handle
directories and files differently. I'm not sure which you mean here;
I suspect this example is getting muddled (at least in my head) by
ignoring this distinction. I think there *is* a reasonable
expectation for SVN to behave differently for the two, and there's no
precedent (say, in CVS) for how SVN should handle directories (since
CVS doesn't), so it's still "least surprising" to allow a variation
here.

So, if URL1 and URL2 are files: then the expected behavior for diff
is dependent upon which diff output format you have chosen; they all
have well-defined expectations for this very common situation; some
"respect" and some "ignore" history. Similarly, for merge, the
behavior is well established: if a line has been changed along only
one path, make the change; if a line has been changed along both
paths, conflict (a uniformly history-respecting behavior).

But, if URL1 and URL2 are directories (as in the situation that
started this topic), then "d/a" has a very explicit meaning, which is
distinct and distinguishable from "u", and I "would expect" either
diff or merge to say or do the thing appropriate to whatever really
happened. In diff-speak, if we're talking about a new version of the
same node, then that's a "U" (or "G" or "P"); if we mean a different
node was given the same name, then that's a "D/A". In merge-speak,
if it's a new version of the same node, then the delta should be
applied to the version presently in the target (described above); if
it's a different node, then the target version should be deleted and
the appropriate version of the new node linked in. (There's a
separate topic we've discussed: is it a merge conflict if one line
has changed a file and another has deleted it. For the purpose of
this discussion, assume whichever answer you like for that question;
the point here is that SVN does know the difference between "u" and
"d/a" for directories, and ought to respect it.)

So: I think there is a distinction to be respected here, but it's not
"diff or merge" but "directory or file." In the file cases, I find
compelling precedent for a fairly complex behavior, some of which I
think you describe as "respecting history" and some as "ignoring it."
The controlling model is not expectation about that, but the
"artifact standard" of preexisting tools and their behavior. In the
directory cases, we find ourselves without precedents (at least,
among the CVS users), and we have something very valuable to provide,
and perhaps even something worth bragging about. But again, the
compelling distinction is "what are we trying to do," not "what mood
is the user in today," nor "how to I flip a bit in the code as it
lies today."

-- 
-==-
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