Jack Repenning <jrepenning@collab.net> writes:
> 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.
Yes, you've exactly explained the difference between a file/dir that
is merely changed, versus one that has been deleted + re-added.
That's exactly what we're talking about.
> 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.
> 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."
Let me clarify, using a different route.
We're comparing the behaviors of 'svn diff URL1 URL2' and 'svn merge
URL1 URL2 .' Under the hood, these are both doing the same thing:
asking the server to compare two repository trees. The comparison
engine, svn_repos_dir_delta(), has the ability to create either
history-based tree deltas (noticing whether nodes are related), or the
ability to create path-based deltas (just comparing similar paths,
ignoring historical relatedness.)
Notice -- the working copy library doesn't track history very well.
It doesn't actually care which sort of tree-delta is applied during a
merge, because the *result* will always be the same: that is, the
exact, predicted set of data will be on disk when the merge completes.
Now here's my argument:
Many people seem to think that the 'svn diff' command is most commonly
used as a preview of the 'svn merge' command... and thus that they
should behave exactly the same. I'm saying that based on my chats
with users, this *isn't* the most common use case of 'svn diff URL1
URL2'. (And besides, we have 'svn merge --dry-run' for previews.)
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.
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?"
If 'svn diff' is "smart" and sensitive to history, the user ends up
seeing the deletion of the entire URL1 tree, followed by the addition
of the entire URL2 tree. I maintain this is Bad, because it does not
answer the user's question. 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.
On the other hand, when a user runs 'svn merge', it's important to
replay history... because the only output a user sees are little
letter codes. And they expect these codes to show historical actions,
like "D + A", rather than just applying a path-based diff ("U").
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 25 17:29:08 2003