[ On Monday, October 14, 2002 at 16:32:20 (-0700), Anne McCaffrey wrote: ] > Subject: Re: Problems with Attic permissions > > I have not invited any 'thoughts' or 'opinions' on how > I am using cvs.If you can't answer my question, pls > don't reply;we can go on arguing about the pros and > cons of someone's practices.I don't see any point in > it.
The problem is your practices are not really compatible with the way CVS is designed to work. You need to forget trying to stop your users from using "cvs rm". That's not the problem. Your "medicine" is potentially doing more harm than the "disease" you percieve. The problem of people doing "cvs rm" when they shouldn't is self-correcting when CVS is used in the normal way. You have to trust your users, and trust is a two-way street. They can't be trusted if they are not given responsibility and the knowlege of what that responsibility entails. If you use good strong network security, i.e. run CVS over SSH to a Unix server where all users have unique, real, and proper Unix system accounts, then you have a chance of achieving reasonably decent accountability for all of their actions, and especially their actions through CVS. > I never said that.I use a script to prevent cvs rm. > We altered Attic permissions to prevent users from > manually deleting Attic files. Let's get rid of the script. Let's also get the directory permissions and ownerships fixed so that they are consistent throughout each module, including any Attic directories, just as they _MUST_ be for the correct operation of CVS. Then let's see if things work again or not. I'll bet they do. > My question was "Why is cvs trying to read from Attic > when I do cvs add" Because that's the way CVS works internally. The "Attic" directory is merely an internal optimisation to make certain CVS operations faster in certain circumstances. In normal operation you can, indeed you _must_, pretend that the Attic directory simply doesn't exist -- CVS will create it, and look in it, whenever it needs to, and otherwise it will ignore it when it can (which is what makes it a potential optimisation). -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs