[Top][All Lists]

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

RE: Administering questions

From: Thornley, David
Subject: RE: Administering questions
Date: Mon, 14 May 2001 09:26:44 -0500

> -----Original Message-----
> From: Anita Chacko [mailto:address@hidden
> Sent: Sunday, May 13, 2001 8:57 PM
> To: address@hidden
> Subject: Administering questions
> 1.Is it a good practice to allow every developer in
> the project to add/delete files/directories in the
> repository according to their requirements?Or should
> this be restricted such that only the cvs admin will
> be able to do this?Any good reasons for whatever the
> answer is?Should these additions/deletions be
> documented?

Here, every developer can add or delete files as needed.
The neat thing about SCM is that, assuming that the
developers don't have direct access to the repository
and don't use some of the less-known features of "cvs admin",
everything is recoverable.  If you have an incompetent or
malicious developer, that person can cause a good deal of
temporary confusion, but (after that person is fired), it
will be possible to clean up.

The one problem I've had with having developers add files
is that they often add them only to the branch that they're
on, when they should also be on head.  I've largely solved
that by providing a add-file script for people to use.

> 2.Same question as above with regard to check
> ins.Should the cvs admin handle all the check ins?Any
> reasons for this?

I see no good reasons for this in normal use.  There might
be reasons to have one person do the checkins in special
cases.  Perhaps the repository and development staff are
large, and there have been problems with updating during
large checkins and not getting a consistent view of the
repository.  (Even so, it might be better to have reserved
times for checkins in that case, rather than having an
administrator handle it.)  I'd suggest letting developers
do their own checkins.

> 3.Is there any purpose/use in documenting all check
> ins?
Um, documenting how?  They're already logged in the history
file (if you've turned that on), and will be listed in the
output of "cvs log" for a file.  We require checkin comments
that link the file to the PR, and a list of changed files in
the PR itself (we use Gnats for bug tracking), and forbid people
to check in without a valid PR.  This has been enough to handle
all desired inquiries for us.

> I can't say how much I would appreciate any help as I
> am really at a loss and have no senior persons to whom
> I may put such questions.Infact before me,there was no
> version control system used at all in this project. 
Look on the bright side.  Anything you do will make things a
lot better.  You will almost certainly make mistakes, but
SCM run by somebody who does a pretty good job is much better
than no SCM at all.  CVS runs well in the absence of much
administration (the state of affairs here before I took it over).


reply via email to

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