Re: [Monotone-devel] Time for a release

[Stephen Leake]

Thomas Keller <address@hidden> writes:

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

Yes. 

Can you post your test case? I don't have any attribute conflicts test
cases yet; I wasn't planning on providing resolutions for them, but I
agree this is not a good error message.

How about "no resolution specified for attribute conflicts;
attribute conflict resolutions currently not supported"?

Which raises another issue for the 'merge to main' requirements; is
just providing resolutions for content and duplicate name enough? Are
there other conflict classes that people find particularly cumbersome
to deal with?

> Secondly, there is a FIXME in monotone.texi:
>
> FIXME_RESOLVE_CONFLICTS: – added default resolution for file content
> conflicts

Right; that's my todo list. Which I'm planning to get done this week.

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

Right; also on my todo list.

Another point about the code; the current committed revision
ee57fe487ffcfd442877e9f43cf6c952fa585ecf allows
'resolve_conflict_opts' even on workspace merge commands. That was
before I remembered that there is now way to generate the conflicts
file. So I'm taking those out.

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

That works for me. The current code is about half done. I'll post
updates as I finish things.

-- 
-- Stephe