On Tue, Mar 30, 2010 at 03:00:55PM +1100, Daniel Carosone wrote: > 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.
Note further, if your merge is creating a new node (and slew of new descendants later) that is not being independently created elsewhere, then their test results are not useful since noone has the revs reporting test results. So, really, just don't bother locally merging on the server. Just pick a head, test, pull again, and repeat until there are no untested heads. Then, according to your desired test coverage, you can either sleep or pick intervening untested nodes. -- Dan.
pgp45b4DzvLtG.pgp
Description: PGP signature
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
