Problems with pretxnchangegroup hook
Douglas Simon
"...if other Mercurial processes access this repository, they will be able to see the almost-added changesets as if they are permanent."
Somewhere between Mercurial 1.1 and 1.5.4, this no longer appears to be true. I use a pretxnchangegroup hook in a gate repo to launch a master script to run a bunch of tests on the pending changes. This master script uses a number of slave/remote scripts on other machines to actually do the testing (so that testing is done on the different platforms targeted by the code). The remote scripts obtain a copy of the code by cloning the gate repo (via ssh). If the above statement holds, then the remote clones should include the pending changesets. While I was using Mercurial 1.1, this indeed was the case.
For unrelated reasons, I recently upgraded to Mercurial 1.5.4 on the gate repo machine (and all remote testing machines). After this change, the remote clones no longer include the pending changesets. To reproduce this in a terminal, create and cd to an empty directory and then cut and paste the following commands (or put them in a script and execute it):
hg init gate
echo -e "[hooks]\npretxnchangegroup = sleep 2" > gate/.hg/hgrc
hg clone gate dev
echo 'a new file' > dev/file1
hg -R dev add dev/file1
hg -R dev ci -m 'first file'
hg -R dev push &
hg -R gate log >log.1
sleep 3
hg -R gate log >log.2
diff log.1 log.2
Unless I'm misinterpreting the documentation, the final diff command should report that log.1 and log.2 are identical. However, log.1 is empty where as log.2 is not. Here's the terminal transcript when I run these commands:
~/bug$ hg init gate
~/bug$ echo -e "[hooks]\npretxnchangegroup = sleep 2" > gate/.hg/hgrc
~/bug$ hg clone gate dev
updating to branch default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
~/bug$ echo 'a new file' > dev/file1
~/bug$ hg -R dev add dev/file1
~/bug$ hg -R dev ci -m 'first file'
~/bug$ hg -R dev push &
[1] 16798
~/bug$ hg -R gate log >log.1
~/bug$ sleep 3
pushing to /Users/dsimon/bug/gate
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
[1]+ Done hg -R dev push
~/bug$ hg -R gate log >log.2
~/bug$ diff log.1 log.2
0a1,6
> changeset: 0:4891bc5180af
> tag: tip
> user: Doug Simon <doug....@oracle.com>
> date: Wed Jun 23 17:43:42 2010 +0200
> summary: first file
>
~/bug$
Am I missing something or did the semantics of pretxnchangegroup change at some point? If the latter, what are the current semantics?
-Doug
_______________________________________________
Mercurial mailing list
Merc...@selenic.com
http://selenic.com/mailman/listinfo/mercurial
Greg Ward
> The documentation for 'pretxnchangegroup' at http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html#sec:hook:pretxnchangegroup includes the following:
>
> "...if other Mercurial processes access this repository, they will be able to see the almost-added changesets as if they are permanent."
>
> Somewhere between Mercurial 1.1 and 1.5.4, this no longer appears to be true.
That sounds like *good* news to me. I always thought that this
visibility of an uncommitted transaction was a nasty bug, not a
feature. I wasn't aware it had been fixed, but I'm glad it has!
> I use a pretxnchangegroup hook in a gate repo to launch a master script to run a bunch of
> tests on the pending changes.
Perhaps you should use a changegroup hook instead? Yes, that means
people might push bad changesets, but it seems to me that best
practice these days is to let people commit/push possibly bad changes
and build/test them immediately using a continuous integration server
of some sort. If they did the right thing and pushed a good change,
then they don't have to sit around waiting for their push to complete.
If they pushed a bad change, they'll find out soon enough when the CI
server says "fail".
Greg
Matt Mackall
It's easy to find this change with:
$ hg log -k pretxn -k hook
Or equivalently:
http://www.selenic.com/hg/log?rev=pretxn+hook
(type 'pretxn hook' in the search box)
It changed here:
changeset: 7787:b8d750daadde
user: Matt Mackall <m...@selenic.com>
date: Mon Feb 16 19:35:07 2009 -0600
summary: Introduce HG_PREPEND to solve pretxn races
According to (1.6 feature):
$ hg log -r '7787:: and tagged()'
it was first released in 1.2.
After this fix, transactions in progress are only visible to Mercurial
commands in the hook's subshell (which have the magic HG_PREPEND flag in
the environment). This means, for instance, someone can't accidentally
start pulling transactions that aren't completed and might get rolled
back in the middle of the pull.
--
Mathematics is the supreme nostalgia of our time.
Douglas Simon
On Jun 25, 2010, at 12:13 AM, Greg Ward wrote:
> On Wed, Jun 23, 2010 at 11:47 AM, Douglas Simon <doug....@oracle.com> wrote:
>> The documentation for 'pretxnchangegroup' at http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html#sec:hook:pretxnchangegroup includes the following:
>>
>> "...if other Mercurial processes access this repository, they will be able to see the almost-added changesets as if they are permanent."
>>
>> Somewhere between Mercurial 1.1 and 1.5.4, this no longer appears to be true.
>
> That sounds like *good* news to me. I always thought that this
> visibility of an uncommitted transaction was a nasty bug, not a
> feature. I wasn't aware it had been fixed, but I'm glad it has!
In that light, I agree that the new semantics is indeed better.
>> I use a pretxnchangegroup hook in a gate repo to launch a master script to run a bunch of
>> tests on the pending changes.
>
> Perhaps you should use a changegroup hook instead? Yes, that means
> people might push bad changesets, but it seems to me that best
> practice these days is to let people commit/push possibly bad changes
> and build/test them immediately using a continuous integration server
> of some sort. If they did the right thing and pushed a good change,
> then they don't have to sit around waiting for their push to complete.
> If they pushed a bad change, they'll find out soon enough when the CI
> server says "fail".
Thanks for the suggestion. My concern was letting bad changes into the master repo.
However, I now realize the best approach is to use the changegroup hook in the gate
repo as you suggest. If the tests pass, the test harness will propagate the changes
to the main repo, otherwise it will rollback the changes in the gate. As long as
no-one tries to pull from the gate repo, they should never see the bad set of changes.
-Doug
Douglas Simon
On Jun 25, 2010, at 12:33 AM, Matt Mackall wrote:
> On Wed, 2010-06-23 at 17:47 +0200, Douglas Simon wrote:
>> The documentation for 'pretxnchangegroup' at http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html#sec:hook:pretxnchangegroup includes the following:
>>
>> "...if other Mercurial processes access this repository, they will be able to see the almost-added changesets as if they are permanent."
<snip>
>>
>
> After this fix, transactions in progress are only visible to Mercurial
> commands in the hook's subshell (which have the magic HG_PREPEND flag in
> the environment). This means, for instance, someone can't accidentally
> start pulling transactions that aren't completed and might get rolled
> back in the middle of the pull.
Ok, definitely sounds like an improvement. I guess the HG book will
reflect this change at some point. I left a comment one the online
book site to suggest this.
-Doug