Workflow question, advice...
Doug Philips
dgou at mac.com
Tue Apr 15 20:56:50 UTC 2008
On Tuesday, April 15, 2008, at 03:31PM, "Paul R" wrote:
>If you want to validate on a changeset basis, I don't see how you can
>circumvent this delay problem.
>A naive solution could be :
> 1 : one DEV repo on which people push
> 2 : a daemon runs in it, applies each revision as a patch to a "gold"
> repository, test it, then :
> 2.1 passes to next rev if test succeed
> 2.2 stop and mail if test fails
> 3 : The person responsible of the failure receives the mail, solve the
> problem, issue a new revision to the DEV repo, and reply to the mail
> saying which revision solves this building issue.
> 4 : the daemon then applies both patches (the buggy one and the fixing
> one) then runs the test. Then go to 2.
That had been my first thought, but then I realized how would the daemon
keep track of which heads it had already processed? They are immutable
after all. I suppose it could strip them, but I'm not sure.
Then I thought: Aha! I know, have the developers submit changesets.
The daemon can then dequeue them, apply to a protected tree, and then
either push to gold/stable or generate reject. So a queue of:
changeset-a, changeset-b, changset-c, ...
might end up getting pushed to gold as changeset-a, changeset-c, changeset-k, ...
if and only if the merges are automatic and the tests pass.
>From the responses to that, I gathered it would wreak havoc on the
developers pulling from the stable tree for their next round of changes.
My next thought is just to generate olde-school patches so that the
very construction of changesets and the linearization of history happens
without the synthetic multiple heads?
I'm trying to get to the "KernelPractice" style up flow but with a daemon
running tests rather than a human doing rote boring merges...
--Doug
More information about the Mercurial
mailing list