Slashdot Mirror

← Back to Stories (view on slashdot.org)

CVS Server Administration Tips?

Posted by Cliff on from the care-and-feeding-of-source-repositories dept.

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?"

2 of 79 comments (clear)

  1. The BEST CVS administration method by Omnifarious · · Score: 1, Interesting

    If you have an opportunity to, chuck it and use Subversion instead.

    --
    Need a Python, C++, Unix, Linux develop
  2. CVS standards I use by MarkLewis · · Score: 2, Interesting

    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.