In message <20031030152247.A19060(a)devserv.devel.redhat.com>, "Michael K.
Well, at least the one we use now just hooks into the commitinfo
hook, so no explicit integration is necessary. I think that adding
per-branch acls to the script we have probably wouldn't be too hard
for a perl programmer. What we have is 101 lines of perl, including
I'm always amazed at what folks manage to do with perl. If we can do
it with commitinfo hooks rather than going to a totally different CVS
server codebase then I'm all for doing it with commitinfo hooks. My
experience with commitinfo hooks was that, yes, you can do almost
anything, but that it got rather ugly pretty quick.
If we want to control reading as well as writing, we'd need more
direct integration, such as the two patches above. Dealing with
security issues that might be worthwhile, but there are other
ways to do that.
I'm not terribly concerned about shutting down read access to
I don't think that's all that interesting of an issue for a public project
such as Fedora.
What I want to see is the ability to sandbox developers. Hell, whatever
we end up using for Fedora may be useful for the GCC project since we're
branch-happy these days :-)