On Tue, Jul 08, 2008 at 09:48:32AM -0400, James Carlson wrote: > Richard Lowe writes: > > The plan of record is that initial migration remains internal (I > > wouldn't know the path, but I would assume /ws/onnv-gate), and > > hopefully very shortly thereafter the open portion of the ON gate > > moves to opensolaris.org. > > True, but I don't think we've talked about access methods yet for the > inside-the-SWAN portion. > > 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. Other things that may be used in a gate hook will give different results, so the people writing the gate hooks need to look closely at each hook they choose to use. This (nfs access) would also mean you cannot control the environment in which the hooks execute. And then there's the question of having permission to obtain the repo lock, which will be written to the repo (at least, when accessing over ssh) as .hg/store/lock. For example: $ cd .hg/store $ ls -al total 7912 drwxr-xr-x 3 samqfs_review_bot sam 512 May 19 10:14 . drwxr-xr-x 3 samqfs_review_bot sam 512 May 15 16:47 .. -rw-r--r-- 1 samqfs_review_bot sam 2805830 May 19 10:14 00changelog.d -rw-r--r-- 1 samqfs_review_bot sam 550336 May 19 10:14 00changelog.i -rw-r--r-- 1 samqfs_review_bot sam 4097533 May 19 10:14 00manifest.d -rw-r--r-- 1 samqfs_review_bot sam 550336 May 19 10:14 00manifest.i drwxr-xr-x 16 samqfs_review_bot sam 512 May 14 13:52 data -rw-r--r-- 1 samqfs_review_bot sam 1602 May 19 10:14 journal lrwxrwxrwx 1 samqfs_review_bot sam 14 May 19 10:14 lock -> eagan-mn:11552 And what if they're hung up while holding that lock, and they aren't coming back, and you don't have access to their host or sufficient permission to kill their proc? 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.) Rich asked some time ago if the lock I was talking about, while describing this sort of hang, was created by my gate hooks, or if it was created by mercurial itself--it's this lock, and it's created by mercurial, not by my gate code. Dean
