Re: [Monotone-devel] Time for a release

[Thomas Keller]

Thomas Keller schrieb:
> > 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?

Sorry, I read for show_conflicts now in 0.40 that this is currently not 
possible - probably because the revision does not yet exists in 
database. Probably a harder task...?

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

A few small objections (without being dived too deep into the code 
tonight): I created two small conflicts and tried to merge via mtn merge 
--resolve-conflicts-file _MTN/conflicts. I did not edit the file yet, so 
I supposed an error "resolution entry missing" or something, but I 
rather got an invariant:

roster_merge.cc:1715: invariant 'I(result.attribute_conflicts.size() == 
0)' violated

As long as we have no user UI this and probably other invariants should 
become user errors, no?

Secondly, there is a FIXME in monotone.texi:

FIXME_RESOLVE_CONFLICTS: – added default resolution for file content 
conflicts

Thirdly, I'm missing documentation on the format of conflict resolution 
stanzas (beside "resolved_internal" nothing is mentioned) - this and 
maybe a small example / test workflow could be added to the manual for now?

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

I think I'd go for a compromise: Review the current changes more closely 
in nvm.resolve-conflicts - if all goes well and it gets merged, we 
release 0.41 with your branch. If not or any major dealbreakers are 
found within the next days, we release 0.41 without your branch. 
Timeline is still until next weekend, if we get ready sooner, we can 
release earlier - but there will be no later release than next sunday.

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