Dean Roehrich writes: > My team may switch to mercurial and we'd like our central hg repository to > validate a few things on each changeset. We'd like the server to verify the
Great to hear! However, just to be clear: our current project scope is a little narrower than you might be expecting. We're updating the ON tools, migrating the SFW gate, and then the ON gate. If the work we do ends up being useful for other gates -- and it sounds like your needs below are similar to ON's -- that's wonderful, but for anything else, I don't think we can set our requirements based on anything else. Our scope is a bit too broad as it is. Do you need this in the short term, or can you wait a few months? If it's a short-term need, I don't think we'll be ready for you in time. (And you should be talking with Bonnie Corwin about all of this, if you haven't done so yet.) > format of the commit message (first line is the CR number, space, CR synopsis, > second line is blank,...), and we'd also like to parse the CR number from the > commit message and verify that CR number against the approved CRs for that > repo, and verify that an extra head isn't created,...and more stuff, I'm sure. Yes; ON has similar sanity-checking needs on push. A lot of the work right now is going into Cadmium, the hg extensions that supplant what ON's 'wx' does. The developer tools are a primary focus right now -- gatekeeper tools are next. > An alternative is to use cascading repos; one for pulls, "P", and one for > pushes, "Q". Use pretxnchangegroup on P, and have P execute a changegroup > hook to push to Q. A prechangegroup hook on Q would ensure that only P can > push to it. Yes, having a push-only gate makes a lot of sense if you have to deal with the lack of read-side locking in Mercurial. I don't think we've looked at this issue for ON yet, though. > (This is how teamware is used with on/nv, correct?) No. For ON, we have a single gate machine that exports deleted_files, usr, and public as read-only file systems, and Codemgr_ws as a separate read/write file system. That means that clients can do bringovers and reparent to the gate, but can't do putbacks. To do a putback, you log into the gate machine, and you then have read/write access to all and can putback. The only reason that's done is to centralize the access control on the gate machine. Unlike Mercurial, Teamware doesn't allow bringovers to run while a putback is being run, so no similar consistency problem really exists. The separate ON clone gate (also on the gate machine) is used to get more parallelism. Because putbacks lock out bringovers and vice-versa, and we don't want to have thousands of people competing for a single reader/writer lock, we've got a clone that periodically (but less often than putback) brings over from the gate, and that gets hit with all the reader locks from the rabble. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
