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.
pgp2F3xPXEdxv.pgp
Description: PGP signature
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel