Workflow question, advice...

[Peter Arrenbrecht]

On Tue, Apr 15, 2008 at 9:10 PM, Doug Philips <dgou at mac.com> wrote:
>
>  On Tuesday, April 15, 2008, at 01:53PM, "Jesse Glick" wrote:
>  >Doug Philips wrote:
>  >> What I want to get to [...] is push to a to-be-validated-repo that
>  >> runs a build farm. If and only if the auto build/test passes do those
>  >> changes then get pushed to a stable tree.
>  >
>  >This is fine and easy to set up, so long as you understand that
>  >
>  >1. Changes pushed to this validation repo are permanent; if they break
>  >something, you need to push a new change to fix it.
>
>  That is a downside. I had thought of using the post changeset commit transaction hook, but the tests take too long to run, which the wiki points out....
>
>  ...
>
>
>  >#2 and #3 are why it may be better to have multiple such validation
>  >repos, to insulate developers from each other to some extent (whether on
>  >a team basis or just by some arbitrary grouping). In such a case you
>  >need bidirectional synchronization with the main stable repo. It is
>  >possible for this synchronization to be fully automated (excepting merge
>  >conflicts which need to be resolved manually).
>
>  So I am beginning to think that pushing is just the source of pain. Perhaps sending bundles would be better, the validator process can then keep its tree hidden from push or pull, apply the bundle, run the validation build/test and then either rollback and send a rejection notice or push it on the stable tree. The stable tree would be pull-able from everyone, but only gets "pushed to" from the validator...
>
>  The validtor could then accept for consideration changesets that cause a merge, but, only if the merge is automatically resolveable -and- still passes the validation. That would take the pull-merge-attempt-push-later-rinse-repeat loop out of manual processing. I suppose it could even do the rebasing and linearize "away" any merges... ???

I've no personal experience with the problem, but the topic came up
before and I think having some sort of push/merge queue where you
enqueue your bundles for merge/push would help with contention. It
could simply send back feedback on problems by email for async
operation, or directly for sync operation from within an extension
(the latter of which might incorporate a pull, too).

One could also, as you said, have the server attempt an unattended
rebase. With a synchronous command, it might then be possible to add
client-side logic that strips away the original changesets prior to
merging the server-provided rebased version. For asynchronous
operation, this would be more  of a pain. And async operation might be
necessary if the server does additional processing like extensive
tests for each bundle it processes.

But it sure adds a lot of complexity to the setup, so, much as I like
Hg, it makes me wonder if it really is a good match for this type of
scenario.

-parren