Thomas Keller <[EMAIL PROTECTED]> 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 _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
