[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS and policy control
Re: CVS and policy control
Thu, 12 Sep 2002 16:35:01 -0500 (CDT)
> 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:
> Can I modify taginfo to prevent deletion of branch tags
> and moving of tags (labels) that I created for baseline
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
> 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
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
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