[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merging confuses renamed files

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-08-22 20:26:13 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.