Dean Roehrich writes: > On Tue, Jul 08, 2008 at 09:48:32AM -0400, James Carlson wrote: > > I suspect that the /ws automounts are problematic for the converted > > Nevada gates. As I understand it (and an hg expert should correct me > > ;-}), when hg runs with a file system path, it runs gate-side > > scripting in the context of the invoker or just refuses to run it at > > all. > > The gate hooks would run in the context of the invoker.
And therein lay a problem. That's not how gate hooks have traditionally run, and it's probably about a foot and a half too much rope. Instead, they mostly run off of email-triggered scripts on the gate machine. That's why I was advocating (inside the SWAN) either ssh- or web-based access for _all_ gatelings, where we can centralize the gate-side controls. We'll also likely need to go there once the gate is accessible outside the SWAN, so we might as well get used to it now. Not sure about others, but the less Teamware baggage we can manage to lug around, the happier I think I'll be. > One scenario I was hitting for a while: We want strict cstyle enforcement for > our project, and that means the gate has to run the checks. We had one user > create a file that was so large, and generated so much cstyle output, that > mercurial and the cstyle tool deadlocked on each other. In that case, on my > ssh server I will find the above lock in place, and if I kill the hung cstyle > process the gate hooks will error out and mercurial will unroll the > transaction and release the lock and the repo will return to a sane state. > > (I've tested Rich's CStyle.py+ProcessCheck.py fix for that hang, and it does > resolve the problem.) Yes; I saw that one go by. Good to hear that one's fixed. ;-} -- 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
