Re: [Monotone-devel] Re: 3-way merge considered harmful

[Oren Ben-Kiki]

On Friday 13 May 2005 07:18, Nathaniel Smith wrote:
> Another option is to use something like codeville-merge, in which a
> version is defined by its state, but its state includes information
> on "how it got that way".

Right. That's a variant along the way to a full Darcs-like system.

> ... A common developer intent is, "take
> everything new in this side and everything new on that side and smush
> them together to make something that has both".
>
> And in this phrasing, my argument is that there is, in general, no
> ancestor that expresses that intent.

"This side" and "that side" refer to some known point, otherwise they 
are meaningless - which is exactly the problem. So I completely agree 
that if all you have is the topology, and you are given _only_ the ids 
of two revisions to merge, in general there's no way of automatically 
computing this base point:

> > Certainly the system can compute the correct ancestor for a
> > particular intent, such as merging a branch back to the main trunk
> > etc. However, I suspect that any such algorithm must, to some
> > extent, rely on meta-information that is not available in the
> > topology itself (call this the expected development "workflow").

Monotone (like many other "new" systems) walks along the thin line 
between being completely workflow agnostic - which is great in theory, 
but in practice makes it impossible to provide many very useful 
operations; and enforcing a specific workflow, in which case you can 
provide all imaginable useful commands - as long as you follow that 
specific workflow. Git and Aegis are good examples close to the end 
points of this spectrum.

Ideally, Monotone would use a layered approach. At the "workflow 
agnostic" level, monotone should allow a 3-way merge that would require 
all three revisions to be specified. Then, in a "workflow aware" level, 
it is possible to provide algorithms that compute the correct ancestor 
for common intent. You can't have it both ways - being "workflow 
agnostic" and computing merge ancestors.

This means that some commands would simply not be available in the lower 
level. A clear-cut example is "pass review" - not all workflows even 
have the concept of a version state which includes formal reviews. If 
there was an easy way to create workflows on top of a basic layer 
(using Lua hooks or shell scripts or whatever), then issues such as 
computing the best merge ancestors for various intents would naturally 
belong there.

> The problem is that people really do want to create arbitrary graph
> topologies.

As long as monotone is not going to provide an explicit "workflow" 
concept, I think that providing a default simple least-common-ancestor 
algorithm would probably find the right ancestor in most cases. It is 
important that the algorithm will detect when the DAG is too complex 
for the result to "make sense", and in this case it would require the 
user to provide the base revision manually (this should always be an 
option). For extra credit, allow dry-running it, and maybe even print a 
list of likely candidates in case of a complex DAG.

> ... Certainly, having a solution that works for arbitrary DAGs is
> much more confidence inspiring than having a bunch of different
> solutions that only work in particular special cases, and then just
> hoping that no non-special cases ever show up.

The thing is, using a particular workflow, one _knows_ that only 
particular special cases will ever arise, and it makes perfect sense to 
use a simple algorithm tailored to that workflow/special cases...

Have fun,

        Oren Ben-Kiki