504325 - single head hook doesn't do its job?

Status: RESOLVED INVALID

(Developer Services :: Mercurial: hg.mozilla.org, defect)

Description

[Axel Hecht [:Pike]]

In http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/pt-BR/pushloghtml, we ended up with an awkward state of the repo.

I.e.

lots of landings on default, then a relbranch on the head of default, and a check-in on top of the head of that relbranch that claims to be on default. No, no idea how to do that.

Now, that should have been caught by the multiple heads hook, IMHO.

I tried to fix the bustage by merging a fake landing on the old default head with the new one, but I can push that.

It smells like in our current setup, the repo that's given to the pretxnchangegroup doesn't contain the changesets to be pushed.

So the hook doesn't check whether you're adding a head, but if you added one previously, and if you did, you can never fix it again :-(

Comment 1

[Axel Hecht [:Pike]]

Precise output:

pushing to ssh://hg.mozilla.org/releases/l10n-mozilla-1.9.1/pt-BR/
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 1 changes to 1 files
remote: Two heads detected on branch 'default'
remote: Only one head per branch is allowed!
remote: transaction abort!
remote: rollback completed
remote: abort: pretxnchangegroup.a_singlehead hook failed
abort: unexpected response: empty string

Comment 2

[Axel Hecht [:Pike]]

PS: this is what I'm doing in python locally:

workbook:pt-BR axelhecht$ python
Python 2.5.1 (r251:54863, Feb  6 2009, 19:02:12) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from mercurial.ui import ui as _ui
>>> ui=_ui()
>>> from mercurial.hg import repository
>>> repo=repository(ui)
>>> repo.branchtags()
{'GECKO191_20090623_RELBRANCH': '[P\xa37\x8e!\xf0o\xd9\xd0\xe7C\xc9\x82+\x1ca/\xa0\xd4', 'GECKO191b99_20090604_RELBRANCH': '\x9f\x86\x85;\xee\xcau\x8aKv\xefNB\xcaF:\n\xa2\xb7Y', 'GECKO191b3_20090304_RELBRANCH': '\x85\x1e\xafZ\x88\xafU\xb4?\xd1\xc6\xbc\xfb\x95j\x18\xd9\xb0m\xaf', 'default': '\x9b\xa1\x83:Nt\xfd\x89\xf5\x88\x1d\xc8|t5\x9f\xaa!<e', 'GECKO191b1_20081007_RELBRANCH': '8E\xaa\x81\x8d\xb1\x11\xe2<\xd5\xc0!c\x8fw\xbb\x97\x9a\xf3:', 'GECKO191_20090612_RELBRANCH': 'EX}\xb0\xec\x8a\xc3SIg\xc5U\x93\x1awAG zF', 'GECKO191b4_20090423_RELBRANCH': '\xf7\x8aSh\xc7\xf7\xc1\x00\xc7\xb6\xea\xa0\x9a(\xa5\xc0z\x96\xb10', 'GECKO191_20090616_RELBRANCH': 'B>\xcc\xc9oZ\xe4\xd7\xa4\x13<,\x1cW0z\xe4M\x07g', 'GECKO191b2_20081125_RELBRANCH': '\xa0\xa5\xf4d\xcd\x12\xda\x91\x03\xab\xbf\x8a\xc0\x13\x1d\xa7\x95\x0e\xe0\xeb'}
>>> repo.branchheads('default')
['\x9b\xa1\x83:Nt\xfd\x89\xf5\x88\x1d\xc8|t5\x9f\xaa!<e']
>>> len(repo.branchheads('default'))
1
>>> for b in repo.branchtags():
...         if len(repo.branchheads(b)) > 1:
...             print "Two heads detected on branch '%s'" % b
...             print "Only one head per branch is allowed!"
... 
>>> ^D

which is what http://hg.mozilla.org/users/bsmedberg_mozilla.com/hghooks/file/4c01dfce70b9/mozhghooks/single_head_per_branch.py seems to do. Passes locally just fine, but fails upstream.

Comment 3

[Dirkjan Ochtman (:djc)]

What version are you running locally? This might be busted because of the changes in handling of pending changesets for hooks, which I think changed in hg 1.2 (which was just recently deployed to hg.m.o).

Comment 4

[Axel Hecht [:Pike]]

Locally, I'm running 1.3 right now.

I didn't test the code as part of the hg hook itself, though, I'm running the code plain in python just yet.

I didn't see a test in the hghooks repository for the single head hook. Benjamin, do you happen to have one lying around or should we create one?

Comment 5

[Benjamin Smedberg]

I don't have one, no.

Comment 6

[Axel Hecht [:Pike]]

So what are the next steps here?

The pt-BR repo is still busted, and we can re-hit this problem any time for any repo that has this hook on.

I personally don't know how hard it is to fix the hook with the data that hg 1.2 provides.

Do we take that risk, do we still need this hook, or do we revert hg.mozilla.org back to 1.1 until we have fix? Aravind?

Comment 7

[Aravind Gottipati [:aravind]]

(In reply to comment #6)
> So what are the next steps here?
> 
> Do we take that risk, do we still need this hook, or do we revert
> hg.mozilla.org back to 1.1 until we have fix? Aravind?

I have no idea.  Its Benjamin, Ted and others that write this stuff.  I merely deploy stuff as I am told.

Comment 8

[Dirkjan Ochtman (:djc)]

http://hg.xavamedia.nl/mercurial/crew/rev/b8d750daadde is the changeset that introduced the HG_PENDING environment variable. The idea and first version of the patch are described at http://www.selenic.com/pipermail/mercurial-devel/2009-January/009838.html. From the description, it would seem like in-process hooks like the Python hooks Mozilla uses would already use the pending data, but I'm not sure how that would work. Unfortunately I don't have much experience with this part of hg, so I can't say much more.

Comment 9

[Benjamin Smedberg]

What we think happened. Before the hg upgrade, the repo looked kinda like this:

* 189 - branch GECKO1911_20090715_RELBRANCH
|
| * 187 - branch default
| |
| * 186 - branch GECKO191_20090623_RELBRANCH
|/
* 181 - default
|
* 179 - branch GECKO191_20090616_RELBRANCH
|
* 167 - branch default

hg 1.1 apparently didn't count this as multiple `default` heads, but hg 1.2.1 does. Arguably hg 1.2.1 is more correct. In any case, I've merged the default heads back together. The hook should prevent this disjunct branching in the future. Jeferson, when you update please use `hg up default` instead of `hg up tip` to avoid problems!

Comment 10

[Jeferson Hultmann]

Thanks! I never thought "update tip" could be evil.