Greg A. Woods wrote: > Version control is a part of software configuration and > change management. I thought that (what you said) is what > it (change management) was all about! ;-)
Argh. I don't think I'm getting my point across, am I? OK, forget I said "change management". The problem is that I (the repository administrator) often have *NO CONTROL* over how the system YP entries and groups are set up, because it's controlled and decided by some bureaucrats sitting 3000 miles away in an air-conditioned control room. Worse, it's often some gruesome hack on top of a Windows domain or something like that.. If this (Unix-level access control) is the only way available for me to control access to files, I am UNABLE to implement any access control at all. Look, we all want to use CVS, because it's free. I agree, we're all weaselly cheapskates who want everything for nothing :-). I merely pointed out the "competitive" thingys to make the point that others are doing this, _because it has been repeatedly asked for_ by customers who face such problems every day. What I'm asking is whether anyone is interested in the sort of ACL work being done on the CVSNT "fork" (about which I asked earlier: has it truly forked for good, then?), and which I haven't examined in a great amount of detail yet, but which seems promising. YES, I understand that its security is not perfect. It's a lot better than not having any damned control at all. After all, I don't have hostile hackers roaming the halls and my network trying desperately to work around the security in CVS. Heck, if I have hostile hackers loose in my network, I have a *@#$load of more problems than whether they can read a particular source file.. Or is the philosophical opposition to such grafted-on mechanisms so great here that no one is ready to even consider any sort of feature in CVS that might dare whisper of the access control heresy? (I see a lot of mention of "Unix" this and "Unix" that. Problem is, this is used in a lot of environments which aren't even Unix. At least, the clients often aren't Unix. For instance, the most common Java development configuration out there is a Linux server and Windows clients, because Sun's JDK on Windows runs rings around Sun's JDK on Linux and even Solaris. Go figure..) -- Shankar. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs