[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:
<snip...>
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
true:
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