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
_______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
