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.
> >> 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. 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. >> 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. > >> 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. > >> 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. I'm not basing the cutover on availability of ssh keys so developers can do work. I presume Mark will take that into consideration. -dvd
