Dean Roehrich <Dean.Roehrich at sun.com> writes: I'm not going to get chance to look at this fully for a while, but there's a couple of bits I can mention.
> Can someone please tell me what kind of enforcement checks are run on a > TeamWare gate? Obviously comchk isn't one of them... :) Nothing is run in a way that is enforced. putbacks always go back, however you may also be yelled at both automatically by software, and perhaps even manually by gatekeepers. See: http://src.opensolaris.org/source/xref/scm-migration/ongk/gate/pbcheck (note that the ongk workspace there is basically never kept up to date, I think that same stuff in its real location is /ws/onnv-gate/public/{gk,gate}) > These hooks can take a while to run, especially comchk, and that leaves enough > time for me to sneak in an 'hg clone'. I'm able to clone the pushed csets > before it aborts the transaction in pretxnchangegroup.Yexit1. That's the race between the changelong being updated, and the transaction completing that we talked about. I still think your own locking is the most effective solution. > If the user issues ^C while runchecks() is running then I have to find the > remote-side hg process and kill it to release the repository lock. It's not > clear to me that adding signal handling for SIGHUP to runchecks() would > resolve this issue. Something to try, anyway. Or maybe I can do it in > hg-ssh? That I don't know about, repo.lock/wlock are released by __del__ methods which run when GC gets to them. What we found with an older issue that used to be in cdm (and that Matt warned us about), is that python's GC won't deal with circular references, so you can get yourself into a state where the lock objects will never actually be GC'd. I have no idea if that's what's happening to you (I'm not certain if by "repository lock" you mean repo.lock/repo.wlock, or a lock of your own). -- Rich
