Re: [Monotone-devel] merge chaos nodes

[Daniel Carosone]

On Mon, Mar 29, 2010 at 03:38:58PM -0500, Hugo Cornelis wrote:
> The easy solution is not to do local merges.  The undesirable result
> of this decision would be a reduction of the frequency of running the
> tests.

Not at all.  When multiple heads arrive, simply pick one.  If you
like, try pulling again once after a short delay, just in case a merge
arrives. 

Imagine you pulled a moment earlier, just before the
second head arrived on the server, and ran the tests on the first of
the heads.  You'd have testresults for that revision, which you can
publish and which will be just as relevant and interesting later on
when that revision has descendants - regardless whether those
descendants exist and are known at this precise moment.

> So we would really like to understand why and in what
> circumstances such a local merge can lead to an unresolvable merge
> chaos.

See the merge picture on the homepage?  That arose during a mergefest
at the summit in Germany, just because several of us were doing the
sync-and-merge cycle at the same time, each with partial information.
It did, of course, eventually converge because they were all automatic
merges, but more interior nodes were created than might otherwise have
been needed. 

Now, if any of the incoming merges had been manual, they can conflict
and your automatic merge attempts will fail.   Your automatic merger
works most of the time, because the merge produces the same result as
is likely to be generated elsewhere and this is by definition the same
revision.  When that revision and its descendants arrive from the
outside, the databases have converged again.

If it ends up creating a unique merge that isn't created outside, your
situation arises.  Imagine the heads in question were merged
differently in the outside world, perhaps manually or because other
revisions were known and a different order was picked, and every other
real developer gets these merged nodes to base new work from, your
unique local merge will continue to be a local head. You'll then
continue merging that with incoming heads, creating new unique local
heads, until eventually that conflicts with other incoming changes.

Are you publishing your test results as testresult certs?  If you are,
another option is for your automated merge nodes to be published to
the outside world again in that sync - perhaps in a different branch
according to your preferences.  That allows external developers to see
those revs, and publish further information to resolve any conflicts
(manually fixing merges, suspending revs, etc).

--
Dan.

pgp0TcErp6eGy.pgp
Description: PGP signature