David Marker <David.Marker at Sun.COM> writes: > Richard Lowe wrote: >> David Marker <David.Marker at Sun.COM> writes: >> >> >>> The scripts are starting to take shape now. >>> >>> We have most of the hooks we want. >>> Just to be clear, we are aiming for parity this time around. >>> That means we check RTI in changegroup not pretxnchangegroup. >>> So push without RTI approval means backout (just as it does today). >>> Still missing: cstyle check. >>> >> >> Is that a similar issue to that with RTI? >> > Yes cstyle will be a changegroup hook. And it will do what we do today: > make sure you left the code as good as you found it (not make sure its > perfect). > So that does a cstyle on the files in the clone with various options > until it passes > and then does it on your version of the file with whatever options > worked on the > clone.
Right I know that, I was wondering if you were having speed issues with it or something (as with RTI). >> >>> I remain concerned about the "hook window". I know its small, but >>> having sanity.py take several seconds still means there is a chance >>> for somebody to pull from the gate and get a changeset that is >>> destined for rejection. >>> >> >> I still suggest locking in the hooks. >> >> > I've given locking some thought. And I think that is more grim than > having 2 repos. You can easily end up with a locked gate until I > come along and notice its stuck because you can't trap the abort > from Mercurial when a pretxnchangegroup hook either returns non-zero > OR raises an exception. So if something bad happens in sanity.py (an > exception I didn't account for) you get rolled back. But the lock is > not getting cleared. You can detect a stale lock however. lock file == symlink to destination hg-$HGUSER.$PID If you come to the lock and would block, check that $PID is still around... > Do users trying to pull just sleep? Or get rejected? If I reject them > that makes > clone updates and incremental builds have to come in some back door. > > And what interval do they sleep? Do I make them wait in a loop checking > every 5 seconds? > > I'm just not sure anything besides the coarse locks I added are really a > good idea > for an SCM that doesn't want to be locked. I'm not certain, when I've thought about it, it seemed easier than having two repos do it. I would think depending on how you structured it, that readers would sleep on the lock (practically, likely, check it every so often and try again). >>> Mark had begun testing the hooks before he left for vacation. >>> >>> I also got a first stab at clone update script. This one shouldn't be >>> as vulnerable to the "hook window", as I make it wait before >>> determining which revision to pull over to the clone. >>> >> >> ... which would require locking, surely, so you have what you'd need >> in general? >> > No, it knows that sanity.py runs on the order of seconds. > So it gets time.time() and holds onto it for a while. > > Then it goes and gets the last revision < that time. Its basically going > around > the hook window with a heuristic. After you pass sanity.py you are in. > Doesn't > matter if my script to generate a webrev fails for example > (non pretxn* hooks that fail mean you just go on to the next, no rollback). > > So by getting a time then waiting before doing the `hg log` to find the > revision > we want it *probably* misses the window. Ah. >> >>> Still to be done: >>> set up our test bed to do clone updates, nightly builds, incremental >>> builds. >>> >>> If it can do all that we will be in good shape. Yes that means that >>> things like >>> the biweekly build may be a manual operation for b97. But that's my problem. >>> That won't affect ON developers. >>> >> >> Which bits of that are you lacking? I *think* that many of the things >> that happen under there are at least simple in concept. >> > Yeap. Provided I set up the env files for nightly/incrementals and the > nightly script still > does the right thing they should go quick. With any luck I just have to > get some > workspaces in place. I'll know more when I've tried it. > > The biweekly does a bit more. And it has to synchronize with clone > update. But a lot > of those scripts run off the email nightly sends. I am not re-writing > anything that will still work. Right. >> >>> I'll be scripting all weekend. >>> And Mark and I will hit the testing hard starting Monday (when he returns >>> from vacation). >>> >>> I'm not setting up webrevs, but I keep the repo fairly current as I add >>> things: >>> ssh://anon at hg.opensolaris.org/hg/scm-migration/onnv-gk-tools >>> >>> All comments are welcome. >>> If you are internal we do have a "fake gate" set up that we play around >>> with. >>> >>> I am not spending time worrying about how we are going to get users >>> public ssh keys. Hopefully when Mike gets back he can help us take >>> what hg.os.o already has to seed the gate. >>> >> >> That's a really, really small time window between Mike returning and >> _97, isn't there? >> > > Yes, but nobody else came forward with access to public ssh keys. > Even a possibility Mike won't be able to get them to me very quickly. tonic-ops, perhaps, though I wonder if you'll run into a privacy policy. -- Rich
