Workflow question, advice...
Peter Arrenbrecht
peter.arrenbrecht at gmail.com
Sun Apr 20 18:37:44 UTC 2008
On Sun, Apr 20, 2008 at 4:22 PM, Douglas Philips <dgou at mac.com> wrote:
> On 2008 Apr 20, at 3:26 AM, Peter Arrenbrecht wrote:
>
> > On Tue, Apr 15, 2008 at 9:10 PM, Doug Philips wrote:
> >> 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... ???
>
> > 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.
>
> Yes, qualifying changes through an extensive set of tests
> (5 minutes at the minimum, 4 hours max) is exactly what I want to do.
> Right now our CVS based workflow doesn't suffer from the merge problem
> when developers aren't in each other's way (95% of the time).
> What I am trying to do is automate the regression acceptance.
> It is completely mechanical work (does the test suite continue to
> pass)...
>
>
> > 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.
>
> Really, that is sad. The whole kerneldevelopment style of feeding
> changes
> upstream has highly automatable parts to it. My larger goal here is to
> have
> the first "gate" be the automated testing. Then a reviewer can look at
> the
> code to make sure it meets the style guidelines (boring job, but doesn't
> take long and might even itself be semi-automatible), and then the
> important
> review is making sure that the code meets its requirements.
Heh, it piqued my curiosity. Since I am anyway writing an extension
for handing off some jobs to the server (rclone, rqinit, etc.), I'm
going to try something like `hg integrate` which tells the server to
take a lock on the repo, then auto-merge and push. This "taking a
lock" should act like a queue when multiple users do this
concurrently, properly serializing the merge attempts. So each
integration causes at most one merge changeset. This could then be
extended to handle rebasing, too. It would be simple, but synchronous.
-parren
More information about the Mercurial
mailing list