Question about pretxnchangegroup

[Doug Simon]

On Nov 8, 2008, at 2:23 AM, Maxim Vuets wrote:

> On 11/8/08, Doug Simon <Doug.Simon at sun.com> wrote:
>
>>> As for me, it looks like you have chosen a wrong way to verify a
>>> commit,
>>> because every push will take some time.
>>> I think it is better to have two repos: first one for development
>>> purposes,
>>> second one for stable and tested versions of a product.
>>
>> This is exactly what I have: a 'gate' repo that is push-only and a
>> 'shared' repo that is pull-only. When developers push to 'gate', the
>> push tests run and if they succeed, then a automatic push is done  
>> from
>> 'gate' to 'shared'. I'm using various hooks to enforce the push-only
>> and pull-only restrictions.
>
> 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.

> 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?

>>> ---you see that the state of a repo during pretxnchangegroup hook
>>> reflectes commits that are commiting now.
>>> So just call some script which will do "hg up -C", make test build,
>>> perform tests and as a result return 0 or non-0 for success and
>>> failure respectively. I think there are no reasons to worry about
>>> state of working dir after not successful commit (assuming that
>>> this repo is just used like a common storage).
>>
>> Actually, this contradicts the following statement from the HG book
>> (http://hgbook.red-bean.com/hgbookch10.html#x14-24600010.9.9
>> ):
>>
>>     "It [the hook script] must also not modify the working  
>> directory."
>>
>> I learnt this one the hard way. If you do indeed do a 'hg update' on
>> the working directory of 'gate' during a push that fails, 'gate' is
>> pretty much corrupted. Any subsequent hg commands performed in 'gate'
>> fail with error messages about unknown node identifiers.
>
> Hmm, really. Thanks for the hint! I just have tried the following  
> script
> and gotten "abort: 00changelog.i at 2edab44de854: no node!".

Yep, that's the kind of thing I was running into.

-Doug