CVS Server Administration Tips? 79
Twintop asks: "The company I'm working for has asked me to take over administration of their CVS server for a decent sized project. The current setup of the CVS server needs to be wiped clean and started fresh. The only times I've ever used CVS (and used it poorly at that) was with a few SourceForge.net (An OSTG Site) projects. What are some suggestions on reference materials for a newbie to CVS (but not to Linux) and methods of administration that have worked for you in the past?"
The CVS Book (Score:3, Informative)
cvs with ssh (Score:5, Informative)
this way, any files created/modified within that directory will retain their group writable permissions. you'll need to set the CVS_UMASK variable for each user as such in the shell of the remote machine they'll be using CVS from.
you'll need to set the CVS_RSH variable to ssh, so it tunnels:
and your cvs home will look something like:
to make it even more convient, i suggest you research ssh-agent/ssh-keygen and use keys. no more passwords, with security and group protections
Re:The BEST CVS administration method (Score:5, Informative)
One thing to remember is that although subversion may be the new hotness, it's the NEW hotness. By this i mean that while there are certainly bugs and problems in cvs, they are most likely *known* bugs and problems - unless your usage is way out there on the cutting edge, the likelihood that you will discover a brand new never seen before bug in cvs is quite low. Sadly, the same can't be said for svn - not because it has quality issues but because it's a younger product. Whilst it's true that no open source project gets very far without users and bug reports, this is still something to keep in mind when making a "cvs vs svn" decision.
Just my 0.02$
Re:cvs with ssh (Score:3, Informative)
Don't forget the :
cvs -dAnd any tweaking of options beneath CVSROOT.
I mentioned this briefly in my secure CVS setup guide [debian-adm...ration.org]...
BRL-CAD's has 20 years of CVS/RCS History (Score:3, Informative)
Several years ago, many of the current CVS practices were written down and organized into a rather detailed generic CVS policy [sourceforge.net]. It basically all boils down to being able to guarantee a certain level of functionality, being very careful about naming directories, and coming up with good tag naming conventions. Likewise, depending on how many developers you have and how active development is, more or less control may be required for branches and validation.
Those last two restrictions are mainly due to limitations of CVS -- it does not directly manage directories or maintain history of directory changes, so you're left up to tracking those changes by policy conventions. (It's rather annoying that a CVS checkout does not prune empty directories by default!) If your directory structure is likely to change frequently (e.g. a new large project starting up), then something like SVN may be less painful. that said, BRL-CAD's history has easily endured CVS's inadequacies quite successfully.
Tortoise/IDE with built-in CVS support (Score:3, Informative)
For Windows developers, TortoiseCVS [tortoisecvs.org] is highly recommended (as well as it's subversion equivalent, TortoiseSVN). For Java users, Eclipse has built in CVS support, which also works quite well.
Re:The BEST CVS administration method (Score:4, Informative)
Actually, one of the great things about Subversion is that it's pretty much just an incremental upgrade from CVS.
For basic, day-to-day tasks, the only thing you need to switch is the word "cvs" with "svn" on your command line (or switch from TortoiseCVS to TortoiseSVN). "svn co/checkout", "svn up/update", "svn ci/commit" all work just fine.
I've switched over several groups (usually 5-20 developers) and the time to get back to work for each was in the order of half an hour or so (a lot less for some developers).
The biggest comment that I've had from those groups is that "Subversion is a relief". All of a sudden, the things you need to be careful with (renaming files, creating/moving directories, etc) with CVS are no longer issues with SVN.
ViewCVS works with Subversion, plugins exist for Eclipse, NetBeans, Forte and .NET. Command line is highly compatible with CVS. All-in-all it's a pretty easy switch, with lots to gain and not much to lose.
Re:The BEST CVS administration method (Score:3, Informative)
> One thing to remember is that although subversion may be the new hotness, it's the NEW hotness.
We have been using it for a year on a medium sized project with a team of a dozen developers, and although some interfaces with other stuff are a bit green, we have not encountered a single annoying bug. It is stable, it makes sense and it removes most of the limitations I have encountered in CVS. I cannot see a reason to go back to CVS.
Re:BRL-CAD's has 20 years of CVS/RCS History (Score:2, Informative)