David Marker wrote: > Urgh. On further reflection I'm still pretty sure it won't work. > Already discussed a bit with Rich. > > Here is a pastebin link of the problem (also added below but if your > mail client > doesn't have fixed width it will look ugly): > http://pastebin.com/m10c38176 > > The dashed lines are context switches. > > For a moment or two there I thought that maybe if the process doing the > pull cached the changelog before checking for the "push-lock" it would > be OK. But (a) it doesn't, and (b) if it did that would probably cause > hg to crash when it tried to read files that a rollback truncated. Or at > least defeat the whole purpose of bothering with a lock. > > So it really seems to come down to pretxnchangegroup hooks imply > you have a repository that is push only and a second repository that > is pull only. The push only repo can move a validated push to the > pull only repo (which doesn't need any check beyond "did it come > from the push-only repo?" which incidentally can be checked in > prechangegroup safely). So there would never be a race with the > pull only repo. No matter what point in time your pull reads the > changelog it is valid. > > Now as we intend to have a clone anyway... perhaps the correct thing > is to say the new Mercurial clone isn't just updated at 11PM Pacific. > Rather it is constantly updated with successful pushes to the gate > (which nobody is allowed to pull from). Making it the pull repo. > > That may cause heartburn because now gatelings who want just > "yesterdays" bits need to do: > hg log -R clone-repo -d "<valid hg datestring" -l 1 > Then pull over to that revision. > > But do they really want 11PM source? I mean we've always had > a clone mostly to give gatelings a place they can get reasonably > current source that won't interfere with others trying to putback. > > But I'm not seeing a way out of the hook window that doesn't involve > two repositories. If anybody else knows a way please chime in. > > -dvd > > Well although it does mean we will have to be very careful on Mercurial upgrages on the gate, there was a way to avoid the race. See pushlock.py (recently pushed to ssh://anon at hg.opensolaris.org/hg/scm-migration/onnv-gk-tools).
It turned out to be pretty simple to force the repo to read up the changelog in preoutgoing. It does mean another lock. But readers hold it just long enough to read the changelog. And if that is misleading. They readup some of the header, but most importantly get the size of the changelog. This does mean readers can block writers. But it should be for very short periods. Writers on the otherhand can end up blocking readers for longer periods, while all pretxnchangegroup hooks are running. But, pretxnchangegroup hooks presently take seconds. If we do ever have them cstyle and check RTIs in pretxnchangegroup they would lock out readers for minutes. And at that point I would go back to saying we must have a push-only gate and a pull-only gate. -dvd
