Jack Repenning <jrepenning@collab.net> writes:
> Leaving aside my doubts as to whether this is actually relevant to
> John's original question, yeah, I think I object. I'm very
> uncomfortable with the rationale you propose. Not the least of my
> discomfort is, I can't for the life of me figure out what your "when
> you do this, you do or don't care" ideas imply about what (you think)
> I expect to see on screen!
Jack, I'm not making up "what users expect" on a whim. My proposal is
based on real feedback from users... although understandably, you've
not been on this list long enough to be aware of this feedback. I'll
give evidence below.
Let me summarize the history here:
- In the beginning, 'svn diff' and 'svn merge' both honored ancestry.
- Recently, cmpilato made both command ignore ancestry by default.
- I'm proposing that just 'svn merge' go back to honoring ancestry by default.
* 'svn diff' behavior -- what do users expect?
Not too long ago, 'svn diff URL1 URL2' used to confuse the heck
out of people. Often the two trees would be independent imports
were nearly identical, and the screen output would be a zillion
'-' lines to delete 'foo', followed by a zillion '+' lines to
re-add another file named 'foo' that was ancestrally unrelated.
And this would happen over and over on every changed file. Users
would complain: "what the heck? There's only one-line difference
between these versions of 'foo'. Why doesn't it just *diff* them
like I expect?" And then we'd go off on long explanations about
how the files were unrelated to each other, and how to make them
related in the future, yada yada.
All the confusion vanished when cmpilato (recently) made 'svn
diff' ignore ancestry by default. It now does "what users
expect". No more spurious deletes/adds of what looks like the
same file. It just diffs the two files directly.
* 'svn merge' behavior -- what do users expect?
Granted, this is more based on a personal feeling, rather than
coming from user feedback. When cmpilato made 'svn diff' ignore
ancestry by default, he *also* changed 'svn merge' to do the same,
and I think it was a mistake. As I said in an earlier mail, *I*
don't want to see "U foo" during the merge, when somebody actually
bothered to delete and re-add the file. That's covering up the
intent of the changeset. Merges are all about keeping things
related, and if the old 'foo' and the new 'foo' are unrelated, I'd
like to know! Is there a counter-argument I'm missing?
> I think "least surprise" means "it did this the last time, it should
> do it again this time." It's about repeatability. It also means "if
> I'm seeing some characters on the screen, they should mean the same
> thing here that they did the last time I saw the same characters."
Can you be more specific? What's inconsistent? Why *specifically* is
the inconsistency confusing?
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" ?
> It's not about razor distinctions, it's about clarity. In this realm,
> it's also about consistency with established precedents--the zillion
> diff and merge tools we've all used before. No version control system
> is an island....
What precedents? What intuitions are we contradicting here?
My experience is that users running 'svn diff' expect a 'dumb' diff,
and users running 'svn merge' expect a 'smart' merge.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 22 20:31:26 2003