[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Time for a release
From: |
Stephen Leake |
Subject: |
Re: [Monotone-devel] Time for a release |
Date: |
Mon, 01 Sep 2008 02:38:50 -0400 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (windows-nt) |
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