[Alexey Mahotkin - Sun at 04:28:16AM +0400] > Rationale: a very common task is "let support engineers commit > patches to the stable branch, and not to the trunk, which is for > main developers only";
*nod*. Or the opposite, untrusted developers might commit to an experimental branch, while the main developers decides what should be allowed to go into the official version - or what is to be regarded as "clean bugfixes" and go into the stable branch. I hope you've read through the ACL discussions that have been the last days. From my point of view, ACLs in CVS could be useful, though not so important that I would try to deal with it myself, at least. > - tag (non-branch) revisions (this includes moving and > deleting tags); I'd favor a distinction between deleting (thus moving) and creating (non-branching) tags. Rationale: Maybe an individual developer can want to set a tag, to be able to go back to this exact version of the source. It's a trivial thing to do, it wouldn't harm anyone, and I'd say that's one of the things tags are to be used for. Then again, it would be very annoying if some other causual developer removed or deleted this or other tags on his own liking. I can also see situations where it might be a good idea that somebody only are allowed to tag the files they have write permission on. Rationale: Tags can be used to mark certain milestones. There might be an agreement about using the tag "m-4" for "milestone 4" which is properly defined in some design document. One developer might, on a casual thursday, find that his part of the project seems to work, and accomplies with all the targets defined for "milestone 4" in the design documents. He should then be allowed to tag _his_ files with "m-4" before continuing with the targets for milestone 5 - without worrying whether the other developers have reached milestone 4 yet or not. I wouldn't say it's important ... but then again, if ACLs are to be implemented in CVS, it should be done Properly, to cover any need that might arise. > Quality Assurance > ================== > > All of the ACL-related functionality is fully unit-tested and > (hopefully) feature-tested. I hope you've read through the discussions that have been here. ACL is a security thing, and security things can never be covered only by testing. At least, the sources should be carefully investigated by several parties. If the purpose of ACL merely is to avoid that somebody by accident steps on somebody elses toes, it might not be that important - but at least it has to be docmented very clearly. Of course, if ACLs are to be secure, people cannot be allowed access to the repository - all operations has to go through CVS. So, either CVS needs to be setgid or setuid, or it needs to run strictly as a server. Setting up SSH so that the cvs users can authenticate and start CVS, but nothing else, is probably the best solution. Then it's important to safeguard that there are no possibilities to shortcircuit CVS. There are talkings that CVS would need almost a ground-up rewrite to be secure, and the info pages also states that once cvs has write persmissions to repository it is possible to execute other commands through CVS. It has to be dealt with if ACLs are to make sense. Good luck! :-) PS: msk.ru, that's in SPb, isn't it? Could be nice to meet over a beer or something - I'll be in SPb until the end of the week. -- Unemployed hacker Will program for food! http://ccs.custompublish.com/ _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
