Closed Bug 623505 Opened 14 years ago Closed 13 years ago

Update to recent Mercurial (2.0.2)


( Graveyard :: Server Operations, task)

Not set


(Not tracked)



(Reporter: timeless, Assigned: cshields)




(Whiteboard: [downtime 1/13 9am-12pm PST])


(1 obsolete file)

Currently we're on hg 1.5.4 (something 6 months old). Hg 1.7.3 was just released, we should at least get to 1.7.something so we're not on an old version.

To do this, someone needs to test our hooks+extensions+templates ala bug 511305 and ensure everything works fine (and passes all the unit tests).

Upgrading to 1.7+ gives support for pushable bookmarks

please? thanks :)
Just to be sure, don't deploy 1.7 (1.7.1 is an unscheduled bugfix release). But 1.7.3 probably makes the most sense anyway.
I had to update the hgpoller test harness to work with hg 1.7, but after doing that all the hook and pushlog tests pass for me with:
Mercurial Distributed SCM (version 1.7.3+2-5d1bb1174047)
Assignee: server-ops → aravind
Toss this back to us, when you guys are happy it all works well?  You have access to the staging server so feel free to hack on things there all you want.
Assignee: aravind → nobody
Component: Server Operations → Hg: Customizations
QA Contact: mrz → hg.customizations
While everyone's at it... there's Mercurial 1.7.5 for some weeks now, and possibly another version once March comes along...
If it matters at all, all the build slaves are going to be 1.6 or 1.7 shortly.
Depends on: 666870
Summary: Update to Mercurial 1.7.3 → Update to Mercurial 1.9.1
Investigating a possible 1.9 upgrade, I've identified a problem caused by something in our templates.  Attempting to serve hgweb with our templates enabled results in the following exception. Using a standard template resolves the problem.  I haven't had a chance yet to investigate in depth.

mod_wsgi (pid=1919): Exception occurred processing WSGI script '/repo/hg/webroot_wsgi/hgwebdir.wsgi'.
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/mercurial/", line 247, in increasingchunks
    for chunk in source:
  File "/usr/lib/python2.4/site-packages/mercurial/", line 214, in _flatten
    for j in _flatten(i):
  File "/usr/lib/python2.4/site-packages/mercurial/", line 207, in _flatten
    for i in thing:
  File "/usr/lib/python2.4/site-packages/mercurial/hgweb/", line 245, in header
    yield tmpl('header', encoding=encoding.encoding, **map)
  File "/usr/lib/python2.4/site-packages/mercurial/", line 329, in __call__
    stream = proc.process(t, mapping)
  File "/usr/lib/python2.4/site-packages/mercurial/", line 263, in process
    return _flatten(func(self, mapping, data) for func, data in
  File "/usr/lib/python2.4/site-packages/mercurial/", line 256, in _load
    self._cache[t] = compiletemplate(self._loader(t), self)
  File "/usr/lib/python2.4/site-packages/mercurial/", line 93, in compiletemplate
    parseres, pos = p.parse(pd)
  File "/usr/lib/python2.4/site-packages/mercurial/", line 82, in parse
    res = self._parse()
  File "/usr/lib/python2.4/site-packages/mercurial/", line 42, in _parse
    token, value, pos = self._advance()
  File "/usr/lib/python2.4/site-packages/mercurial/", line 31, in _advance
    self.current =
  File "/usr/lib/python2.4/site-packages/mercurial/", line 70, in tokenizer
    raise error.ParseError(_("syntax error"), pos)
ParseError: ('syntax error', 469)
Do you have the patch from bug 666870 applied? changes the header template, which this seems to stumble upon.
Cool, that patch seems to fix the problem on my test system. Thanks Axel.
I've refreshed the patch from bug 666870 such that it applies against the current contents of with their inline JS and CSS.
Mercurial 2.0 is about to be released probably at the start of November:
I think upgrading will greatly improve how long it takes to push to try. See
Summary: Update to Mercurial 1.9.1 → Update to recent Mercurial
This is a server-ops task.

At the moment, this looks like something we could mix in during the move to scl3, which means Q1/Q2 of 2012.  Doing it earlier than that will preclude already-defererd maintenance and refactoring that we really need to take care of.
Assignee: nobody → server-ops
Component: Hg: Customizations → Server Operations
QA Contact: hg.customizations → cshields
Punting to cshields, this is for SCL3.
Assignee: server-ops → cshields
Whiteboard: SCL3
Generally what we've done to sanity check a new version of Mercurial is:
1) Run the unit tests in the hghooks repository ( , it's just with the new version, verify that they all pass.
2) Run the unit tests in the pushlog repository ( , again) with the new version, verify that they all pass
3) Setup the new version with the hooks + extensions + templates on a staging server (Aravind created hgstage a while ago for this purpose) and manually verify that things look okay in the HTML interface.

The first two steps should verify that none of our custom hooks or extensions are broken. The third step is just a sanity check because it's hard to test that the HTML templates produce proper output.
Mozilla hg infrastructure suffers from a lack of internal documentation.  

So what sounds like a simple upgrade isn't.  We're working on back filling documentation but I'm real hesitant to push hard on this because a) it's working and b) no documentation and c) if it breaks and we can't back out correctly, we have big issues.

Incidentally, we just learned there's a staging hg server (yep, no documentation).  This might help things go quicker but it's sat dormant since Aravind left and I'm unsure of the state.
Comment on attachment 555466 [details] [diff] [review]
Patch against

I pushed this on a new hg_1_6+_updates branch:

I'll merge it to default when we're ready to roll out the new hg to production.
Attachment #555466 - Attachment is obsolete: true
Okay, I've run the hghooks tests and the pushlog tests with hg 2.0.1 on my local system, and they all pass (after applying that templates patch).

This was on:
Mercurial Distributed SCM (version 2.0.1+32-32a6e00e4cfe)
going to draft up upgrade/backout docs and see if we can do this soon.  Will touch base with ted tomorrow on some additional requests he had for testing on irc when we got distracted by an outage.
per email w/cshields, this might be ready to happen next week - pending some last testing. cshields will let us know for certain once he's ready. Flagging for downtime, so buildduty are aware.
Flags: needs-treeclosure?
Corey: we need a downtime this week for bug 715026 and bug 715478 - would this be ready for a ride-along on that downtime?
Flags: needs-treeclosure? → needs-treeclosure+
Whiteboard: SCL3 → SCL3 [downtime 1/13 9am-12pm PST]
We will be doing this with the tree closure on 1/13.

For those of you interested I've outlined the steps we'll be following here:

Backchannel will be #it for the hg portion of the downtime.

During the downtime, external ssh based connections will fail and http connections will show a hardhat page.  Anyone connected to a VPN at the time may still be able to pull, tree closure hooks should prevent anything from pushing, but in any case I'd appreciate no attempts either way until the maintenance is done.
Whiteboard: SCL3 [downtime 1/13 9am-12pm PST] → [downtime 1/13 9am-12pm PST]
FYI: The current Mercurial version is 2.0.2 released on 01-01-2012.

Is it too late to use that version?
(In reply to pretzer from comment #22)
> FYI: The current Mercurial version is 2.0.2 released on 01-01-2012. 
> Is it too late to use that version?

I'll try to get this built and tested before the window.
This update seems to be causing raw HTML files to be served as application/binary; before the update they were served as text/html.  Example url:

Is this a deliberate side-effect of the upgrade?
(In reply to Jonathan Griffin (:jgriffin) from comment #24)
> This update seems to be causing raw HTML files to be served as
> application/binary; before the update they were served as text/html. 
> Example url:
> testing/tps/pages/page1.html
> Is this a deliberate side-effect of the upgrade?

Yes, as of 1.9.1 that is the behavior, and we are now at 2.0.2. See

Well, this upgrade wasn't as clean as I would have liked but it is done for now.  We still have a lot of work to do on revamping and improving the hg infrastructure but I hope this will help.

There were a lot of hgweb changes (nothing real cosmetic - mostly shifts in backend files) so if something appears to look strange file a bug for it.  In addition if something does not appear at all where it use to, there may be a stuck pushlog entry - we had a bit of time where hooks were executing out of order and ended up clogging some trees.

Thanks for assistance goes out to ted, callek, catlee, lsblakk, philor, atoll, fox2mike
Closed: 13 years ago
Resolution: --- → FIXED
Depends on: 718155
Depends on: 718172
Depends on: 718186
Depends on: 718221
Depends on: 718241
Depends on: 718251
Depends on: 718562
Summary: Update to recent Mercurial → Update to recent Mercurial (2.0.2)
Product: → Graveyard
You need to log in before you can comment on or make changes to this bug.