> I am trying to find out how to handle policy control > within CVS at the server level, just like the pre-op > and post-op triggers within ClearCase. > > I have read about the files: > loginfo > taginfo > rcsinfo > editinfo > commitinfo > > Can I modify taginfo to prevent deletion of branch tags > and moving of tags (labels) that I created for baseline > labels? > The question is whether a taginfo script can figure out that the tag it's being asked to move or delete is one you want to stop. If you use standard naming conventions for branches and baseline tags, you can check on the tag name. If not, I don't know any way to tell if the tag is a branch tag (and it might not be a branch tag on all files, although that's usually an error), and it could not tell a baseline tag from any other sort of revision tag. Possibly you could maintain a list (on the server, of course) of tags not to be messed with.
> Can I modify commitinfo to prevent checkin to the main > trunk (we use main for the Production branch and all > the developers work on side branches)? > It doesn't say in the copy of the Cederqvist, I'm reading, or in Fogel's book, and I haven't experimented, but some people on the list have said that the commitinfo script runs in a directory with the files to be committed and the CVS directory of metadata. In that case, you can parse the CVS/Entries file to see if files are checked out on a tag. If the tag isn't a branch tag, CVS will stop the commit, so all you need do is check for a tag of any sort. > Can I modify commitinfo to prevent deletion of files > from the repository? > Again, I haven't experimented, and the manuals are rather vague about this, but I would think you could identify a deleted file either by its not being present, or its being zero-length, or from CVS/Entries. > Also, do I modify CVS so that nobody else but myself can > modify those *info files. and if so, how? > To do this, you want to be the only person with write permission in the CVSROOT repository directory. You should keep the scripts referred to by the *info files there, to keep them versioned and to keep them in the same security "box" as the *info files, and put their names in the checkoutlist file so CVS knows to check them out in the repository when you change them. If you want people to be able to check out these files and look at them, you need to give them read permission to the CVSROOT directory and write permission in a separate lock hierarchy (see http://www.thornleyware.com/scm/cvsconfig/cvsaccesscontrol.html for detailed and (I hope) helpful instructions). > Lastly, is there a way to modify ownership and permission > of the files in the CVS repository so that they are owned > only by the CVS administrator (similar to a post-op > checkin trigger in ClearCase)? > I assume you're using CVS on a Unix box, rather than CVSNT on a Windows machine, because if the latter I don't really know. You don't modify file permissions (although it is necessary for anybody who's going to use the repository to have read access to them) but rather directory permissions, since CVS commits files by creating a new file and replacing the old. This of course does not restrict anybody who's checked the files out from doing what he or she wants in his or her sandbox. I don't know what you mean by a post-op checkin trigger, or why you would want file ownership. Can you clarify? -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
