[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Preventing users from Tagging files
From: |
Mike |
Subject: |
Re: Preventing users from Tagging files |
Date: |
Wed, 26 Nov 2003 08:15:17 -0500 (EST) |
Thanks. Everyone has been very helpful.
You hit the nail on the head.
Adding tags is quite safe, it is the removal of a tag that "messes up" our
repository structure. We do back things up nightly, but its a huge waste of
time recovering from the backups when a tagging mistake occurs.
I've tried out a modified version of the script on my test cvs server and it
works great. I'll move it on over to production next week.
Thanks for the help.
--Mike
--- On Tue 11/25, address@hidden < address@hidden > wrote:
From: address@hidden [mailto: address@hidden
To: address@hidden
Date: Tue, 25 Nov 2003 17:41:47 -0800 (PST)
Subject: Re: Preventing users from Tagging files
On Tue, 25 Nov 2003, Kaz Kylheku wrote:<br><br>> On Tue, 25 Nov 2003, Mike
wrote:<br>> <br>> > I am aware that I can use the unix file system permissions
to prevent<br>> > developers from checking in files into CVS. But is there a
way to prevent<br>> <br>> In addition, you can use the commitinfo scripting
mechanism to stop commits<br>> for just about any criteria: bad code
formatting, missing bug number<br>> in the log message, etc.<br>> <br>> >
people from TAGGING files [or retagging] while still letting them checkin<br>>
> those same files? Or am I just asking a stupid question?<br>> <br>> You can
implement your custom restrictions in a script specified in <br>> the taginfo
administrative file. The taginfo script could check the<br>> user identity and
reject the operation if that identity is blacklisted.<br>> <br>> (But really,
if you can't trust some developers to tag properly, how<br>> can you trust them
to commit anything? Learning a tagging system and<br>> sticking to it is far
less complex than all the things you have to do<br>> to become a competent
software developer. :)<br><br><br>Tagging is not really the issue, it is
deleting tags that is. And once you<br>have deleted a tag, it is gone. I have
always thought this was a weakness<br>of CVS. History of all commits are
retained, even deleting a file from the<br>repository really does not delete
the ,v file, the file is just moved into<br>the attic. But when you delete a
tag, there is no history you can revert<br>from, besides your last repository
backup. Even competent developers<br>can accidentally delete something they
did not mean to. Everyone<br>can be confused from time to time. This is a
strong argument for having<br>good and frequent backups of the CVS repository,
in lieu of some<br>other home grown tag backup mechanism.<br><br>At work, we
prevent everyone from deleting tags, except one user, <br>cvsadmin. This way,
if there is a tag delete snafu, we know who did<br>it. There is our
implementation; YMMV. You could easily make this <br>a more generic
implementation, and lookup the username from a file of<br>authorized
users.<br><br>taginfo entry:<br>ALL $CVSROOT/CVSROOT/tag.sh
${USER}<br><br><br>tag.sh:<br>#!/bin/sh<br># Everyone can add<br>$<br>if [
"$3" = "add" ]; then<br> exit 0<br>fi<br><br># cvsadmin can do
everything<br>#<br>user=`whoami`<br>if [ "$user" = "cvsadmin" ]; then<br>
exit 0<br>fi<br><br># Nothing else is allowed.<br>#<br>echo $@ >>
$4/tag.log<br>exit 2<br><br><br>Adam<br>----<br>Adam Bernstein address@hidden
http://mpgedit.org/~number6<br><br><br><br><br>_______________________________________________<br>Info-cvs
mailing
list<br>address@hidden<br>http://mail.gnu.org/mailman/listinfo/info-cvs<br>
_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!