Re: [Monotone-devel] Re: Deterministic *-merge

[Oren Ben-Kiki]

On Fri, 2007-01-12 at 18:14 -0800, Nathaniel J. Smith wrote:
> Anyway, the answer to your question is that I'm not proposing anything
> at all change in monotone -- that's why I said at the beginning of the
> writeup that my note had no practical consequences :-).

I think that merge behavior is one of the most crucial pieces of how a
VCS behaves. Darcs is an example of this approach taken to extreme, and
demonstrates how a solid theoretical basis for the merge can be viewed
as "the" core design choice of a VCS. Having something equivalent for
more traditional version control systems would be a real breakthrough
IMVHO.

As for practical implications - cherry picking can be defined in terms
of a merge operation, as long as you *really* trust your merge :-)

> We've
> generally taken the line that the history graph should attempt to
> model as closely as possible the user's intrinsic understanding of
> "versioning a bunch of files", because this is the both the most
> user-friendly and the most future-proof approach.  (Sucks to build a
> particular merge algorithm's assumptions into your hash-chained
> history graph, and thus be stuck with that merge algorithm for a few
> decades...)

That's true. On the other hand, there's immense power to be gained from
picking a powerful merge abstraction and running with it (again Darcs is
a good example).

> That said, I dunno, maybe someone will figure out how to use this kind
> of stuff to improve VCS UI -- it's just some ideas, who knows what
> will happen to them once they start wandering around in people's
> heads...

For starters, annotating the '#' with the list of candidate values
immediately suggests an interface for conflict resolution. Also
presumably the cases where "conflict" actually occurs would (hopefully)
be more in line with user expectations. And then there are the advanced
features you could build on top of this (like cherry-picking).

These all require that the chosen merge abstraction be really solid,
which translates to trying to poke theoretical holes in it, and then
trying it in practice for a while, until sufficient confidence is
reached.

Most VCS don't trust their merge method (for good reason). On the down
side, this restrict their power; on the up side, they allow plugging in
different merge algorithms, so it would be possible to implement and
test deterministic *-merge in them to see how well it works in practice.
Monotone is a particularly good platform for this because it is based on
solid abstractions in other areas (what is a version, what is a branch,
etc.)