Vladimir Marek wrote:
>>> I am interested in seeing what happens if you block for a while on
>>> server side during push. But I guess that means that the gate is locked
>>> for another push, if not even for pull. I can whip some examples to have
>>> something to start with.
>>>
>> If you install any pretxnchangegroup hooks, you will want to consider
>> going to a write-only gate/read-only clone arrangement.
>>
>> When a changegroup is pushed, Mercurial opens a transaction,
>> incorporates the changeset(s) into the repository, and then runs the
>> pretxnchangegroup hooks. If any of those hooks fail, the transaction is
>> rolled back, and the repository restored to the state prior to the
>> transaction. If all of those hooks pass, the transaction is closed, and
>> then the changegroup hooks are run.
>>
>> While that transaction is open, other users may pull the new changesets,
>> which is bad, because if you reject them and rollback, they still exist
>> in the other user's repository.
>>
>
> Hmm, actually hg does not behave as you described (and as I found in
> documentation). There seems to be some sort of locking.
>
> In my setup I have gate repository, which has
>
> [hooks]
> pretxnchangegroup.01_test =
> /home/vm156888/Documents/sfw/hg/scripts/display_all_changesets
> pretxnchangegroup.02_test = sleep 10
> pretxnchangegroup.03_test =
> /home/vm156888/Documents/sfw/hg/scripts/just_one_changeset
>
> just_one_changeset fails, so the transaction is rolled back.
>
>
> If I during the 'sleep 10' hook try to clone the gate, I'll get:
>
> $ hg clone gate tmp
> waiting for lock on repository gate held by 'pub:6267' <--- waiting here 10sec
> updating working directory
> 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
>
> and the newly cloned repository does not have anything from the rolled
> back change.
>
> If I try to push, it is also locked out until all the
> pretxnchangegroup-s finish.
>
> I'm using hg 1.0.2
>
> If this is correct behavior, the advantage of having two repositories
> lies only in the fact, that readers are not locked during write.
>
This looks like good news. I am hoping to avoid the gate/clone split
for push/pull that ON has and SFW has under Teamware.
Now the only split we should end up with is "recipies" and "tarballs",
which we can't avoid if we want to keep the changesets reasonable small.
-Norm
