Re: [Monotone-devel] considering no merge-into-dir

[Nathaniel Smith]

On Thu, Oct 09, 2003 at 12:21:30AM -0400, graydon hoare wrote:
> yeah, that might do (unless the files were renamed on each edge).. it
> might also work to, say, write out a bunch of "pristine" trees and a
> control file:
> 
>    tmp/<LCA-manifest-id>/foo/bar.c
>    tmp/<LEFT-manifest-id>/foo/bar.c
>    tmp/<RIGHT-manifest-id>/foo/bar.c
>    tmp/<NEXT-manifest-id>/foo/moved/bar.c
>    tmp/conflict-list.txt
> 
> but, yeah. something "easily" machine-processable like this is, I
> think, slightly better than "<<<" markers, since you can turn the
> former into the latter with only a little glue, and anyways your merge
> tool might actually make a better overall go at it than monotone's
> 3-way merger, even on the lines monotone thinks it "got right".

Eww, renames are an icky bit here, aren't they.  Especially since a
conflict can actually consist in inconsistent renames (either foo was
renamed to bar on one edge and baz on the other, or foo and bar were
both renamed to baz on different edges... or take some arbitrarily
complex combination).  I don't know how you represent such conflicts
in an "offline way".  A stupid solution would be to require the user
to resolve such conflicts immediately even if they're allowed to
resolve textual conflicts at their leisure.

Incidentally, yet another way to deal with textual conflicts is to do
BK-style <<<< markings, wherin each <<<< block contains a unidiff
between an appropriate chunk of the LCA and one of the children.  This
preserves enough information to do a proper interactive three-way
merge, at least for conflicts (it doesn't preserve non-conflicting
changes, though).

> the issue is that tromey might take the opportunity -- if there is a
> mechanism in place to casually do so during a normal, successful merge
> -- to make some semantic corrections during the merge, and thereby
> create a TROMEYMERGE version which actually *fails* to merge with
> GRAYDONMERGE in the future, whereas accepting the automerge and
> applying a fix post-hoc would not cause a future conflict.

Right, that's a problem.  We want to encourage people to get a base
revision into the repository before fixing things, because
deterministic merges make distributed version control happy.

> I read from your suggestion, though, the idea of committing a version
> with '<<<' markers (or, say, a "conflict" certificate) when there is a
> conflict, rather than prompting the user for help or writing out a
> temporary directory and killing the merge half way. 
> 
> since this is all about UI and gut feelings -- nothing is every really
> "correct" when merging -- I can only give my gut feeling, which is
> that I like writing out a temporary directory a bit better. surely
> there's a limit to how smart a merger can be, and it always *might* be
> synthesizing semantically wrong code even when there's no line-level
> conflicts.. but there's something just somewhat yucky-feeling about
> writing versions into a VC database when the VC software *knows* it's
> broken. just my $.02 aesthetic preference.

I also suggested something like the above on IRC.  I don't know if I
like it, but it seems worth thinking about a bit more.

To clarify, the idea is to have a form of merge which, upon
encountering a conflict, marks it like CVS (or maybe uses some more
well-thought-out format), carries on regardless, and then when it
commits the result it automatically adds a big "don't use this!" cert.
My initial impression is similar to graydon's "ew!", but there are
some merits.

  - It preserves deterministic merges.  And this is actually quite
    useful for merges involving conflicts.  If Alice does a merge like
    this, then resolves the conflicts by hand, and Bob also does so,
    then Alice and Bob will be able to easily merge their fixed
    versions.
    (Note that if Alice and Bob just did separate by-hand merges, and
    disagreed at any point, then things can currently get rather
    complicated.  We have 

               FOO   BAR
                | \ / |
                |  X  |
                | / \ |
              ALICE  BOB

    and if we want to merge, we have to pick either FOO or BAR as the
    common parent, which gives bad results.  In particular, suppose we
    pick FOO as the LCA.  Further suppose that in some chunk, Alice
    decided to take FOO's version, and Bob decided to take BAR's
    version.  To the automerger, this won't look like a conflict; it
    will look like a change occurred in BOB that didn't occur in
    ALICE, and Bob's choice will silently win.  This doesn't occur if
    Alice and Bob are both working from a single sorta-merged
    version.)
  - It has the main advantage of merge-into-directory: the ability to
    do some merging, then get tired and save your work-to-date for
    later.
  - It has another advantage, in that you get to use all your version
    control machinery to work out merges.  So if you get sick of
    merging some big conflicts, you can commit a partially fixed
    version and let someone else finish.  And if Alice and Bob both do
    this, then it's easy to merge their partially-fixed version to get
    a more fixed version.  Or maybe you realize that some parts of the
    merge are going to be nasty (maybe the interaction of two features
    requires the addition of some totally new code to the merged
    version); you can commit a version with the easy conflicts
    resolved, in case you later realize you screwed up the nasty merge
    and want to revert it.
    I don't know how important these are in practice, but the stories
    are neat.  Maybe people who have done heavy work with branches
    (i.e., gcc hackers) can comment on this.
  - In theory we'll have other "don't use this!" certs around for
    other reasons, so all the infrastructure to prevent people
    accidentally getting this broken version already needs to exist.
  - This is partly because are all sorts of other cases where you want
    to commit a version that you know is broken.  Maybe you want to
    checkpoint before doing some intrusive changes (and since in
    Monotone "commit" doesn't necessarily mean "put in the giant
    public repository that everyone in the world uses", this makes a
    lot more sense than with CVS).  Or you broke something but can't
    tell what and want someone to help you figure out what's wrong.
    Or just know that you broke some stuff but that's okay because in
    Free Software, Quality Control Is For Releases (TM).  Whatever.

Like I said, the idea of committing versions with <<<<'s in them seems
icky; but, writing all those reasons up has half-convinced me that
this is a misguided prejudice that I should be ashamed of.  Any
thoughts?

-- Nathaniel

-- 
"...All of this suggests that if we wished to find a modern-day model
for British and American speech of the late eighteenth century, we could
probably do no better than Yosemite Sam."