[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

cvs admin command, potential problems

From: Bret
Subject: cvs admin command, potential problems
Date: 10 Dec 2004 08:25:49 -0800
User-agent: G2/0.2

Our CVS admin quit, and the admin duties were turned over to me.  I've
used CVS as a normal user, but never as an admin.  First, here's my
CVS is running on Solaris, the usernames are _not_ tied to the Unix
login.  I don't have root access to the Solaris machine.
I am accessing CVS from a WinXP machine, using the command line program

The issue:
I was told to add a new user, which I didn't know the process.  After
using cvs --help and cvs -H admin, I tried this command from the root
of the project:
cvs admin -a username

The result was that every file in the project got a new time/date
stamp, and the user was still unable to get into cvs.  I eventually
found an file in the CVSROOT directory of the
repository root, and got the user added - so I thought everything was
ok.  Problem then was that the user could not update files.
Also, the ownership (user/group) of all files are cvsuser/other.  The
Solaris admin recursively changed the group to "cvs" (which is the
primary group of cvsuser)on all files and my new user can now update
them.  But anytime something is updated, the group changes to "other".
I know nothing about the "other" group, and neither does the Solaris

I guess my questions are:  what exactly did I do to the repository when
I ran that cvs admin command?  Is that why I'm seeing this "other"
group, or is the "other" group a normal occurance?  What can I do to
back out the changes made by that admin command if they were
detrimental to my repository?

Thanks in advance for any information.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]