[Top][All Lists]

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

Re: CVS newbie - I want to make a new CVS installation secure...

From: Steve deRosier
Subject: Re: CVS newbie - I want to make a new CVS installation secure...
Date: Wed, 19 May 2004 11:55:31 -0400
User-agent: Mozilla Thunderbird 0.6 (X11/20040502)

Flossie wrote:
2) I'm suprised how much CVS docs emphasise the fact that multiple users can check out the same file and CVS can resolve conflicts as checkins occur. However there are problems with letting users resolve conflicts (they can get it wrong), and I doubt a system can be 100% foolproof at deciding that an auto-merge is safe (in which case CVS can get it wrong), although the chances of error are very small.
There are other reasons, but basically, can I disable multiple checkouts?

3) Can I stop the general users from performing things like code branching? Stop them from removing files?

Are there any other tips on tightening up CVS security? Not security in the sense of SSH, etc, but once a user is 'in', limiting what they can do?

Good grief!  Might as well continue: "Can we stop them from checking out files? Can 
we stop them from checking in files?  Can we stop them from editing files?  Can we stop 
them from getting any work done at all?"  :)

Really, what on earth would you want to use CVS for?

1. You don't want to use concurent editing because you're concerned that merges might fail.  We used to have 
some developers at our site that were concerned about this.  A little education and all was better (I've 
never ever once seen or heard of any evidence of CVS screwing up a merge, every screwup I've ever seen was 
user error).  BTW, the "C" in CVS stands for Concurent.  This is the whole point of CVS over 
lock-based versioning systems.  Don't want the "C" then use RCS, and the telephone: "Hey Bob, 
I need to tweek one line in the file you've got checked out, can you check it in so I can actually get some 
work done?"

2. You have hired developers for their skills, you're paying them money, and 
you trust them with your code base, but you don't trust them to take care of 
code conflicts?  Or managing source files? Come on...  If you don't trust them, 
why allow them to work on your code at all?  I'd get people that I felt were 
competent and I trusted in the first place.

3. Multiple checkouts... I hope you're not trying to disable one developer from 
checking out multiple files at once.  If you do, it will be near impossible for 
anyone to get any work done at all.

4. Branching is probably the most importaint feature of CVS (after merging of course).  Disabling 
this would cause every change, even temporary experimental changes, to have to be checked into the 
mainline "stable" codebase.  Which means that you don't any longer get version control 
for your experiments, or you make your "stable" codebase very unstable.

Examine your workflows carefully.  You'll find that one of the following is 
1. A set of files in a commonly accessable directory is all you really want.  
Result: you don't need CVS.
2. Your expectations of either your workflow or your users is wrong.  You can 
and should use the features that CVS gives you.  Result: educate yourself and 
use CVS the way it is intended.
3. Your expectations of the workflow or users is right.  You need a central 
repository and the feature set and phillosophy of CVS doesn't match your needs. 
 Result: don't use CVS; do some research and find the repostory system that is 
right for your needs.

CVS is not a "one-size fits all" sort of program.  It is excellent for people and groups 
that want and need its features and for workflows that match the "CVS philosophy" if you 
will.  There are tons of other code repository/source control/revision control systems out there, 
and if CVS doesn't map well to your needs, then you should fine one that does.  And CVS isn't even 
the only OSS one out there either, though in the long run you might find it cheaper to use the 
right tool for the job even if it costs you money.

CVS works well in our company.  We've had to adjust the habits of some of our 
developers, but after a while everyone settled down and started using it 
properly.  But I recognize that it wouldn't work as well in all cases.  Do a 
little research and maybe you can find something that matches you better.

- Steve

reply via email to

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