Re: [Monotone-devel] Time for a release

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Quite a lot of time (4+ months) passed by since 0.40 was released and
> a couple of things have been implemented and fixed since then. Though
> there are no big highlights, I'd still like to do a release just to
> show that we're still alive. The buildbots (at least those which are
> working) look reasonable green - the freebsd one has a not enough
> memory problem, some seem to be offline, but the rest looks ok.

I'm working on a minimal implementation of conflict resolution; just
content and duplicate name conflicts. The duplicate name resolutions
will only be rename or drop, not suture.

The point of this conflict resolution implementation is to allow
preparing conflict resolutions one at a time, before the actual merge
command is issued. Then when you do the merge, you can tell it to use
the prepared resolutions, so no user interaction is necessary.

This avoids the problem of losing work when you encounter a conflict
that's complicated and abort a merge.

This is the biggest impediment to using mtn for my team at work; they
are scared of merging, because of the uncertainty involved in the
conflict resolution process. This is especially true for propagating
between branches; there are typically many small conflicts that must
be reviewed.

All of the code I need is in n.v.m.automate_show_conflicts, which also
implements suture (but not fully yet). I'm subsetting that into
n.v.m.resolve_conflicts (yes, the branch names are not the best).

Unlike sutures, the implementation in n.v.m.resolve_conflicts doesn't
change any core monotone data structures or database formats, so it
should not break any current functionality.

I plan to get it done this weekend (Monday included; it's a holiday
here in the US). 

I'd like this to be in the next release so my team at work can use it,
without an internal mtn version.

So if we can postpone a release until next weekend, I'd appreciate it.

On the other hand, the mtn command line interface to this feature is
not at all settled. I'm implementing this process:

mtn automate show_conflicts > _MTN/conflicts

add resolutions to MTN/conflicts via Emacs DVC GUI

mtn merge --resolve-conflicts-file MTN/conflicts

Others have expressed a desire for mtn command line operations to add
resolutions to the conflict file. I don't plan on using them, and we
did not come to any consensus on what they might be, so I'm not
implementing them now.

This minimal command line interface is sufficient to get things
started; we can add more commands for the next release, after people
have had a chance to experiment. We can also add resolutions for more
conflicts. In the meantime, any text editor can be used to add
resolutions to the conflict file; it's in basic-io format.

However, if people want more of a chance to review this stuff before
merging it to main for a release, or want to wait for a more complete
implementation, that's fine, too.

-- 
-- Stephe