* Danek Duvall <[EMAIL PROTECTED]> [2006-04-13 11:07]: > On Thu, Apr 13, 2006 at 06:52:48PM +0100, Dermot McCluskey wrote: > > > >>The important point for me is how easily can I update the > > >>configuration file that defines the access control rules. If it can > > >>be done with a COMMIT, then great. If I need to send a request to an > > >>administrator to be actioned in <1 business day, then I've got > > >>problems... > > > If by problems, you mean "presented with an inconvenience", then, > > > sure, I agree. > > > > This could be a showstopper for us. Module owners need a way > > to directly change the access control (eg lockdown a branch) > > and have this take effect immediately, without involving third > > parties. > > +1 > > I liberally lock down the gate to do investigations that might result in an > undo, and that needs to happen instantaneously -- to the point where I > wrote a script to do it, rather than having to edit the access control > file. So yes, the lack of immediate access to repository control is a > showstopper. > > It'd be nice if such changes didn't introduce a changeset into the gate, > too, but that's just a really annoying bug, not a showstopper.
Well, a global lock is intended for v1. But the ability to lock branches to a restricted set of users, or have a preferred set of users who can ignore a global lock wasn't scoped for v1. To do a directory lock without a commit--meaning that there is an administrative interface of some kind--is fine, but not in v1 of the site. I will go and check on the physical aspects of our deployment to see if there's a way to get the source outside (essentially v0), so that I can stop getting in the way of experimentation... - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ _______________________________________________ tools-discuss mailing list [email protected]
