Re: [Monotone-devel] Re: [cdv-devel] more merging stuff (bit long...)

Kevin Smith wrote:

> Nathaniel Smith wrote:
> > My approach it is, when you say "merge that thing into my
> > tree", you're telling the merge algorithm that you do, in fact, want
> > the thing over there to end up in your tree.
>
> That's the way I work with CVS in eclipse, BECAUSE it has absolutely
> wonderful diff preview capabilities. On a hunk-by-hunk, file-by-file,
> package-by-package, or whole-project basis, I can pull in exactly what I
> want, and nothing else.

There seem to be three distinct methods of using version control, and
almost everyone clearly falls into one of the three:

manual merging - all updates are done by manually picking through hunks
and deciding which ones you want. This methodology unfortunately makes no
distinction between skipping over cherry-picking a hunk and deciding that
it should be permanently ignored, so it forces you and everyone else on
the project to do the manual thing. I've done this, and found it to be
excruciatingly painful, but it's the preferred method of many people.

maniacal merging - slightly more under control than manual merging, but
there are always a very large number of branches going on in parallel,
some experimental, some not, and from time to time changes are pulled
between them in a fairly ad hoc manner. The amount of cherry-picking
varies a lot here, and in the extreme it can look like manual merging, but
generally updating is done in a straightforward additive manner.

hate merging - uses a minimal number of parallel branches, and sticks to
the simple commit everything/update everything methodology. This includes
the vast majority of developers including, ironically, a number of version
control developers (me, for example). This group is distinctly
underrepresented among version control early adopters.

Current scms work great for the hate merging crowd, and are okay for the
maniacal merging crowd. The manual merging approach isn't supported very
well in general, mostly because nobody has a good answer for how to
differentiate between a skipped cherry-pick and a reversion. (The
technical problems with just cherry-picking can be quite onerous too.)

> On the other hand, this visual diff actually marks conflicts, and the
> puller has the option to not pull conflicts, or to pull conflicts that
> can be automatically resolved. So with that wonderful tool, the logic is
> all nicely integrated.

Codeville has a command to pull other data and then do diffs without
actually updating, by the way. Doing manual merge in Codeville right now
would make it not have real history though, and make the tool not terribly
functional.

Convergence could sort of help with that. The big convergence question is
what should you do in this situation:

    a
   /|
  / |
 b  |
 |  |
 c  b

If you're convergent, the answer is c. If you aren't, you get a conflict.
Manual mergers and people who do a lot of offline patch trading tend to
prefer c. The vague feeling among other people seems to be that they
dislike it. I tend to dislike it because of the following case:

    a
   / \
  b   b
  |   |
  c   a

In this case because of the implicit undo c should win, but according to
convergence it should behave the same as:

    a
    |
    b
   / \
  c   a

so there should be a conflict.

Looking at this example now though, I don't see any deep reason why you
couldn't make implicit undo take priority over convergence, although I
have no general algorithm for doing so.

I think convergence is a much more controversial feature than implicit
undo. In the case of implicit undo on the 'pro' side we have a common use
case which clearly warrants it and on the 'con' side we have vague
intuitive feelings. For convergence on the 'pro' side we have a common use
case which clearly warrants it (although it can be argued that that use
case is abusive of the underlying version control system) and on the 'con'
side we have ... vague intuitive feelings, plus a lack of an actual
algorithm which implements it properly (although we can manually give
answers to the important simple cases).

The thing convergence can't *really* do properly is parallel file
creation. If two people create a file with the same name, it's very
dangerous to assume that they're supposed to be sutured into the same
file. The fix is to treat files with the same name as a conflict, and have
a suture command. I guess when running suture you could go over the two
file histories and use a convergent merge algorithm to get good behavior,
which would seem to be another argument in favor of having a convergent
merge algorithm.

I'm considerably less down on convergence than when I started this post,
mostly because of how one could in principle make implicit undo take
precedence over convergence in the important special case. There's still
that lack of knowledge of how to support it problem though.

-Bram