Slashdot Mirror
CVS Server Administration Tips?
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 is a free download. You can order a dead-tree version, as well.
tasks(723) drafts(105) languages(484) examples(29106)
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
- tristan
If you have an opportunity to, chuck it and use Subversion instead.
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$
#!/usr/bin/english
BRL-CAD is a very large scale project with over 20 years of history in RCS and CVS. The CVS repository now lives on SourceForge with pretty much the entire revision history preserved (the project only recently released as open source). You can see one of the oldest files, for example here (bool.c). If you look to the end of the file, you'll see something like: Wed Apr 18 02:19:43 1984 UTC (20 years, 9 months ago) by mike
Several years ago, many of the current CVS practices were written down and organized into a rather detailed generic CVS policy. 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.
Cheers!
Sean
You are the reason people do not like to ask questions. And I am not talking just about /.. You have this superiority complex that if you know the answer, or do not like the question, the person asking it must be stupid. Read the original post again. Did he ASK for you to do his job? No. Did he ask you to teach him to be a guru CVS admin in 21 minutes? No. He admitted that he did not know something but needed to learn quickly. He asked for directions on GOOD places to look for answers.
You are right that there is nothing that beats personal experience. Yet you belittle people for asking to learn from the personal experience of others.
I hate to break this to you, but Google is not always your friend. There is a lot of good information and a lot of garbage there too. One must sort out the garbage from the good. But if you don't know enough about the information, how do you tell the garbage from the good? He could spend weeks trying to sort out the info. Which is the option you want people like him to choose. Just as long as it doesn't take any of your precious time. You may be an expert in the field and know the good from the garbage at a glance. Not everyone is. If you are an expert, you may know which are the best terms to use in the search. Is "CVS Administration" better than "Administering CVS?" Perhaps "Best Practices CVS Administration" is a better search term. But someone not knowing CVS could spend way too much time just trying to refine the search to bring up the needed info, let alone actually learning from the best info.
People like you do a lot to lower the average intelligence of humanity. I hope that you never have children. They would learn to be afraid of asking questions. They would learn that it is better to be ignorant than to try to learn.
If you think that a question is stupid, you have the right to that opinion. However, once you have the reputation of a blowhard, there is little point in talking, since few listen to the wind. I, for one, will not listen to the wind anymore.
For Windows developers, TortoiseCVS 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.
The best advice I can give when administering a CVS server, is...Trust No One(TM).
Assume the absolute worst possible scenarios will occur and plan for them.
This means make sure that your system is secured and updated as possible, especially the CVS software.
Force ssh access, don't allow pserver access at all.
Ensure that a daily backup occurs and that you have backups for at least a week.
Triple-check your permissions on all the CVS directories.
Don't run the CVS server as root unless you absolutely have to (and I don't think you have to).
Other recommendations:
1. Keep the directory structure relatively flat, makes updates faster and output easier to scan.
2. Separate different domains into different CVS modules. What I mean is, you shouldn't have to update all the tests and all the documentation, just to update your source tree.
If you have the chance to do it the way you wan't: Don't use CVS. Use Subversion instead. SVN in short: CVS done right. I think it's even being developed by the original CVS developers.
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.
> 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.
Well, of course the obvious advice is to use SVN if possible. This will save you pain in many ways, the most important IMO being individual atomic changesets which track all files affected by one change, so you don't need to ask yourself, "Now what ELSE did the developer commit as part of this fix?" Yes there are ways around this in CVS. But they're not convenient nor are they guaranteed to always work.
That disclaimer out of the way, here are the basic common-sense rules we use for CVS:
1. Make sure you do your builds directly from CVS, not from any development machine. This means that you can guarantee that you have a record of the exact contents of a build and aren't getting any artifacts from a developer system.
2. On a related note, every time you release a version, tag the source with a non-branching tag for later tracking.
3. Whenever you release a product that you will need to maintain separately from your development line (e.g. you ship a product to a client, or release your product to the production web server, or whatever), then create a separate branching tag for it.
4. Periodically review the repository and chastize users who do not use descriptive commit messages or who aren't careful and commit files with only minor (think whitespace) changes.
5. If you are able to use Subversion, look into TRAC (http://www.edgewall.com/trac/) to see if it can help you. It's a godsend.
Heard? Then you actually haven't tried it? I've always heard branching didn't work very well in CVS also, however we implemented it on a large (2000 plus classes), several branches in fact, and it worked fine.