On Fri, May 04, 2007 at 08:55:54AM -0700, Mike Kupfer wrote: > >>>>> "stevel" == Stephen Lau <[EMAIL PROTECTED]> writes: > > stevel> It looks like there was an old errant hg process holding onto > stevel> onnv/onnv-gate, so it never got unmounted (and thus remounted). > > stevel> I've killed it now, which forced the remount, and it looks like > stevel> it should be serving the correct onnv-gate now. > > There's more than one onnv-gate? I don't understand how holding the > filesystem mounted would cause problems.
When I have to do a rollback, I clone the old onnv-gate into the "new" onnv-gate up to the common ancestor changeset. I then push the new rebuilt changesets on top of that, move the old onnv-gate aside, and drop the new onnv-gate onto the "/hg/onnv/onnv-gate" name. Unfortunately, anon tends to have enough traffic of people cloning it that the loopback mount of onnv-gate into /home/anon/hg/onnv/onnv-gate doesn't always timeout, so it has the mount pointing to the old workspace instead. It's usually a simple matter of killing whatever is using that mount (and thus zorking some poor sap's current bringover, but given that it's a bad bringover anyway, i don't consider that too bad), umounting the /home/anon/hg/onnv/onnv-gate, and allowing it to be remounted by the next anon clone. cheers, steve -- stephen lau // [EMAIL PROTECTED] | 650.786.0845 | http://whacked.net opensolaris // solaris kernel development _______________________________________________ tools-discuss mailing list [email protected]
