Closed Bug 573285 Opened 14 years ago Closed 14 years ago

New Hg (1.5.4) doesn't seem to honour hook ordering.

Categories

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

All
Other
defect
Not set
blocker

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: aravind, Unassigned)

References

Details

1) It appears that stuff gets into pushlog before it gets committed into
mercurial.  This shouldn't be happening because this is the list of hooks in
the repo.

[hooks]
pretxnchangegroup.a_treeclosure = python:mozhghooks.treeclosure.hook
pretxnchangegroup.a_singlehead = /repo/hg/scripts/hg_require_single_head
pretxnchangegroup.z_linearhistory = python:mozhghooks.pushlog.log

technically the singlehead should be rejecting stuff and we should never get to
linearhistory (unless this is no longer true in 1.5.4)
Assignee: server-ops → nobody
Component: Server Operations → Hg: Customizations
QA Contact: mrz → hg.customizations
Blocks: 551015
linearhistory is a weird name for "pushlog.log". Also, I think we should be able to run pushlog.log *after* the commit, instead of before? That should decrease the potential for putting something in the pushlog, then failing to commit it and thus getting integrity errors from sqlite.
This is a blocker for l10n. Our infrastructure took a dive and doesn't come back up, as view-source:http://hg.mozilla.org/releases/mozilla-1.9.2/json-pushes shows a push with

 "1397": {
  "date": 1277050717, 
  "changesets": [
   "cd2df3a23e69f81f8d71ec62676568d85b10fd59"
  ], 
  "user": "eakhgari@mozilla.com"
 }

, but that changeset is not in the repo.

We're not making any progress on product l10n until this is resolved.
Severity: normal → blocker
According to the main hg developer, hook handling should now be in the order of specification in the hgrc file (not sorted by name). I am not completely sure how that interacts with having hooks specified in different hgrc files, though (hgstage, for example, has the pushlog hook in /etc/mercurial/hgrc). That might be the problem?
Likely, unfortunate so. The question of multiple config files sounds like a good counter argument.

Regarding running the hook after the commit, it's somewhat a chicken and egg problem of which unlikely incident is more likely, the commit going wrong or the tracking in the db going wrong.
(In reply to comment #3)
> According to the main hg developer, hook handling should now be in the order of
> specification in the hgrc file (not sorted by name). I am not completely sure
> how that interacts with having hooks specified in different hgrc files, though
> (hgstage, for example, has the pushlog hook in /etc/mercurial/hgrc). That might
> be the problem?

Yup, they are listed in multiple files on the hg.m.o servers, we want the pushlog hooks to apply to all repos, but once some of the repos care about the various single head hooks.

I think we should move this to be a changegroup hook, and not worry about keeping it as a pretxnchangegroup hook.  But I can't make that call.  We risk losing the entry in pushlog if something fails at that point.
I changed the hook ordering, the pushlog hook is now called after the changesets commit.

I renamed it to this.

changegroup.z_linearhistory = python:mozhghooks.pushlog.log

That should fix the corrupt pushlog db problem.  If djc or other can come with a better solution, I can always change it back.
Aravind also removed the records for ehsan's attempted cd2df3a23e69 in mozilla-1.9.2, which fixes bug 573403.
Cool, thanks for the sunday shift.

l10n is up again.
Wasn't the idea behind making the pushlog a pretxnchangegroup hook to ensure that if it failed for some reason, the push would also fail? What happens now if the pushlog hook fails for whatever reason, after the push itself succeeded?
We patched our hg installation to honor hook order.  So this bug can be closed.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
Product: Release Engineering → Developer Services
You need to log in before you can comment on or make changes to this bug.