At 10:24 AM -0500 8/25/03, Ben Collins-Sussman wrote:
>Jack Repenning <jrepenning@collab.net> writes:
>
> > 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."
>
>There's no distinction between file or directory behavior.
>
>If a directory was deleted and then re-added, I would expect 'svn
>merge' to replay that exact bit of history: delete the whole tree,
>re-add it. If a file was deleted and re-added, I would expect the
>same behavior. I don't understand the "complex" behaviors that
>differentiate files and dirs... or maybe I do, but I don't follow you
>at the moment.
You missed my point. You have focused on directory-or-file as "the
thing added," while I am trying to draw attention to them as "the
place where something was added."
My point was that SVN can (has enough information), may (has no
conflicting precedents), and should (would be more usable, would be
clearer to the user) distinguish between "a change to a file itself"
and "a change to a directory itself." The behavior we're discussion
is "recursive diff"; its recursion means (among other things) that it
uses some of what it learned while examining a directory to modify
what it does with the contents it finds there. At the most trivial
level, it uses the list of contents as a modifier (definer, in fact)
of what contents there are. I suggest it also use the containing
directory's information about whether the same-named contents are
really the same object (versions of the same node).
SVN knows more about changes to directories than it does about
changes to files. If I transform this file:
line one
line two
line three
into this file
line one
line 2
line three
by deleting "line two" and inserting "line 2", or if I do it by
deleting only "two" and inserting "2", or if I do it be replacing
"two" with "2"--SVN has no slightest idea which approach I took.
But if I have a *directory* with three components of those names
(bizarre thought, but bear with the example, please), and make any
one of those changes, SVN knows exactly which course I took, because
I can only take that course through SVN commands. This is a cool
thing about SVN, that it not only knows but records these
distinctions; blurring them at certain parts of the UI is confusing.
Might be justified, but it needs extraordinary justification to
violate the fundamental UI model so thoroughly.
>I think the most common use case of 'svn diff URL1 URL2' is comparing
>trees that are *unrelated* to each other... and therefore this command
>should produce a path-based diff by default.
Color me mystified: if URL1 and URL2 are unrelated, then don't you
get the same output with or without --notice-ancestry?
>A common use-case here is when someone imports two different releases
>of 3rd party software. On the one hand, we have a fancy
>svn_load_dirs.pl script that helps users *force* the two imported
>trees to be related to one another. On the other hand, many people
>don't use that script. And when they run 'svn diff URL1 URL2',
>they're simply asking the question, "what changed between releases?"
Ah ... you're saying "the user foolishly created trees that do not
record their relationship within SVN," right? The trees are
conceptually related, but the user neglected to mention that to SVN
during the import. As a result, SVN naively repeats back to them
"wow, man, you got a whole *bunch* of unrelated stuff, here!"
You think that, in this case, SVN can have the intuition (if not
indeed clairvoyance) to "do what the user meant, not what he said,"
inferring a relationship where none has been attested by the user. I
guess I'd say that the use case "botched the import" is real enough
to deserve some support, but need not be the "common" one that drives
the defaults.
>I've talked to users, I've seen them
>surprised by this... it's not what they expect to see. They expect a
>path-based diff.
No doubt. People are generally surprised when reality does not match
their expectations. In this case, you might do them the greater
service by helping them "take their first step into a larger world"
of versioned directories. Versioned directories is not an "under the
hood" thing for SVN, it's a user-visible feature -- indeed, one of
the chief selling points. Not only does it deserve to be known by
the user, not only does it provide great value for the user, but it's
even wonderful enough to justify the trouble of educating the user.
--
-==-
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
Received on Mon Aug 25 21:18:08 2003