[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: 3-way merge considered harmful
From: |
Oren Ben-Kiki |
Subject: |
Re: [Monotone-devel] Re: 3-way merge considered harmful |
Date: |
Sun, 15 May 2005 21:07:31 +0300 |
User-agent: |
KMail/1.7.2 |
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
- Re: [Monotone-devel] Re: 3-way merge considered harmful, (continued)
- Re: [Monotone-devel] Re: 3-way merge considered harmful, Brian Campbell, 2005/05/03
- Re: [Monotone-devel] Re: 3-way merge considered harmful, Sergio . Garcia, 2005/05/04
- Re: [Monotone-devel] Re: 3-way merge considered harmful, Oren Ben-Kiki, 2005/05/07
- Re: [Monotone-devel] Re: 3-way merge considered harmful, Nathaniel Smith, 2005/05/13
- Re: [Monotone-devel] Re: 3-way merge considered harmful,
Oren Ben-Kiki <=
- Re: [Monotone-devel] Re: 3-way merge considered harmful, Oren Ben-Kiki, 2005/05/07
Re: 3-way merge considered harmful (was Re: [Monotone-devel] merge weirdness...), K. Richard Pixley, 2005/05/02