Re: [Monotone-devel] Time for a release

[Thomas Moschny]

On Monday 01 September 2008 Thomas Keller wrote:
> Stephen Leake schrieb:
> > 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.
>
> That sounds pretty cool already. Does this work for workspace merge as
> well, i.e. update?

It should, or at least I would be surprised if it didn't.

> > 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.

Do all tests pass?

> > 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.
>
> I'd definitely like to have some people look over the code before it
> gets merged.
>
> > So if we can postpone a release until next weekend, I'd appreciate it.

While a review could be done in a week, I'm not sure we should really be in a 
hurry. We can easily have a 0.42 in a month or so.

> > 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.
>
> A usable command line would probably be needed, otherwise people which
> don't use Emacs (like me) will find the interface then pretty academic
> and won't use it.

Yes, I also think that a cmdline interface for recording resolving decisions 
is needed. Not everyone is using emacs. At least the format of MTN/conflicts 
must be documented properly. Also, test cases are needed. (Maybe this is 
already done, didn't find the time yet to have a look at that branch).

> > 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.

> I'm undecided - even though I wear this nice release manager hat, I
> don't like to say just "yes" or "no" here. I perfectly understand that
> you need it for your team and that people should be encouraged testing
> it and all, but I fear that once the code went into mainline, the
> general (your?) interest making a halfway usable command line which does
> not include editing basic_io files is gone by then...

> Other opinions?

Not meaning to discourage you, Stephen, but at this time, and with Thomas 
wearing the release manager cap already, I'd say, we'd better have 0.41 done 
now, and have your work merged in afterward. Having a 0.42 release within 
short time then would be fine and fully justified even by a single new 
feature. But of course the decision is up to Thomas as he's doing the work ;)

- Thomas

signature.asc
Description: This is a digitally signed message part.