Question about pretxnchangegroup

[Maxim Vuets]

On 11/10/08, Doug Simon <Doug.Simon at sun.com> wrote:

>> Maybe would be better to do all this in a bit different way?
>> 1. One commits to a "gate" repo.
>> 2. "Gate" hook launches build and testing _in the background_.
>> 3. Right away a verification is done "hg push" from "gate" to
>> "shared" repo is perfomed.
>
> The primary goal of the setup is to prevent unverified change sets
> getting to 'shared'. I don't see the drawback to having the testing
> done when developers push to gate. That is, there will always be a
> serialization bottleneck due to each (group of) change sets being
> verified. The only constraint is that the execution context of the
> push will be unresponsive until the tests are run. If that is a
> command line in a terminal, then there's no issue.

You can make autobuild daemon and some kind of FIFO.
1. Developer clones shared, does changes, commits them to gate
2. Gate's hook passes last-known-working-rev (current state) and
expected-tip-rev (commited changes) to autobuild daemon's FIFO.
3. Daemon performs in background build, testing and
a) pushes changes from gate to shared in case of succeess
(hg push --rev may be used also), or
b) strip commited changes in case of failure.

It's just a rough example. I may be wrong somewhere, but
it also may give you some thoughts how to make commits easier
for developers. (:

>> Or yet another way: do nothing on pushing to "gate", but every
>> hour/day/week run autobuild and send reports via e-mail. Then
>> push changes to "shared" by hand.
>
> How would one identify which of a bunch of pushes caused the tests to
> failed?

hg bisect (=
Or logically: an one guy commited UI changes and a second one
commited network-related stuff, then if some HTTP-test fails, so
the second one did a bug.
Anyway I'm sure that each developer must be responsible for
testing his/her changes.

-- 
 .  Hoc est simplicissimum!
..: maxim.vuets.name