Re: [Monotone-devel] Time for a release

[Thomas Keller]

Stephen Leake schrieb:
> 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.

That sounds pretty cool already. Does this work for workspace merge as 
well, i.e. update?

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

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.

If the others are ok, I guess we can easily release a few days later. 
(After all, we've already waited four months...) My wife and son are 
away from Wednesday, so I guess I'll have more time for different things 
then anways ;)

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

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

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

--
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature