Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Linux Business Programming IT Technology

CVS Server Administration Tips? 79

Posted by Cliff 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?"
This discussion has been archived. No new comments can be posted.

CVS Server Administration Tips? More

CVS Server Administration Tips?

Comments Filter:

  • If you have an opportunity to, chuck it and use Subversion [tigris.org] instead.

    • Thats what I was going to say. If you're starting over, might as well go with the right tool.

    • Re:The BEST CVS administration method (Score:5, Informative)

      by tanguyr ( 468371 ) <tanguyr+slashdot@gmail.com> on Tuesday January 18, 2005 @02:25PM (#11397878) Homepage
      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$
      • This argument could also apply to experience. Everyone I work (directly) with knows CVS. I don't know of anyone who knows subversion. The submitter describes "a decent sized project". If this also involves a 'decent sized' company, chances are, CVS-use will be far more productive.

        Having said that, I have yet to delve into subversion and it may well be a far superior product, for all I know. Maybe maintain a smaller project using subversion at the same time; your bosses will (probably) respect the fact that

        • Re:The BEST CVS administration method (Score:4, Informative)

          by danpat ( 119101 ) on Tuesday January 18, 2005 @04:53PM (#11400328) Homepage

          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.

          • You've convinced me: I'll check it out. I rate CVS highly and, if what you say about svn is correct (I have no reason to believe otherwise), it can get even better!

            Thanks :-)
            • One single thing that's important for me: Atomic commits. Beautiful thing and it works.

              Although Subversion's performance is as good as CVS when used with a large number of files (read bad) its usability and security features make switching worth. I use it to store every bit of code and document I wrote at home and work in addition to our regular revision system. Makes life easier in the long run.

              Although some CVS junkies prefer fsfs back-end, I prefer the database one, at least it is recoverable easily. eas

      • > 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.

      • there's always the possibility that there may be some horrible bug waiting there, but if in general you can always checkout your code and you keep regular backups, there should not be a problem.

        CVS's little idiosyncracies seem to cause a lot of problems for my developers. Things like commits not being atomic, for example. Granted, working around CVS' limitations is not rocket science, but I'm already asking them to know so many different things, CVS just seems to be just one more stumbling block for th
        • While there are programs to convert CVS repositories to Subversion repositories, I am not aware of any that do the reverse. Of course, it would be possible to write one usi.
          • True, but in my opinion it's probably liveable to know that releases 1-5 are in CVS;, 6-9 are in SVN, and 10 and later are back in CVS.

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

      Seconded. From a development standpoint, it takes a couple days to get used to the new way of doing things (revision # tracking is project-based, not file-based; branches and tags are really the same thing), but the features it offers (directory tracking, file moving, etc) are worth the switch!
    • This is absoultely true. Subversion is an excellent SCM and ready for large-scale use today. There is only one warning: DO NOT use the BDB store. It's awful to administer and scales very poorly. Use the fs store ("svnadmin create --fs-type fsfs") and I think you'll be very happy.

    • I have yet to actually use SVN, but I'm soon going to as a new project I've joined use it. From the description I got it was CVS but with the biggest "gotchas" fixed. As other people in the thread mentioned it is very easy to migrate for developers.

      We got a tip that there is a good book on SVN out from O'Reilly (who else?) and it's also available online, for free Version Control with Subversion [red-bean.com].

      BTW the project I joined is hosted on BerliOS.de which is a Sourceforge like system which supports SVN for hoste

  • The CVS Book (Score:3, Informative)

    by Short Circuit ( 52384 ) * <mikemol@gmail.com> on Tuesday January 18, 2005 @02:00PM (#11397538) Homepage Journal
    The CVS Book [red-bean.com] is a free download. You can order a dead-tree version, as well.

  • Cederqvist, the "official" manual, is surprisingly well-written, and worked wonders teaching me about CVS. Highly recommended, and available for free in a variety of formats at the CVS web site [cvshome.org].

  • cvs with ssh (Score:5, Informative)

    by OmniVector ( 569062 ) <see my homepage> on Tuesday January 18, 2005 @02:23PM (#11397851) Homepage
    i'd use cvs with ssh. you'll want to give everyone an ssh account on a particular machine. create the cvs directory and give it a group sticky bit:

    mkdir /srv/cvs
    chmod 2770 /srv/cvs
    groupadd cvs
    chown root:cvs /srv/cvs

    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.
    export CVS_UMASK=002

    you'll need to set the CVS_RSH variable to ssh, so it tunnels:
    export CVS_RSH=ssh

    and your cvs home will look something like:
    export CVSROOT=:ext:username@hostname:/srv/cvs

    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:cvs with ssh (Score:3, Informative)

      by stevey ( 64018 )

      Don't forget the :

      cvs -d /src/cvs init

      And any tweaking of options beneath CVSROOT.

      I mentioned this briefly in my secure CVS setup guide [debian-adm...ration.org]...

    • There seem to be a lot of comments saying nothing more than "use ssh!", and worryingly they are being modded up by the slashdot sheep who can't see beyond using CVS on the public internet like their pet open source projects do.

      The article author has been a bit vague about his requirements, but he did mention that this is for a project team within his company. In all likelyhood his users are all on a secure LAN, and ssh will buy him nothing but added complexity. Possibly more useful if his clients are all

    • 379955903618604798669887 --MarkusQ
      • how's that encoded?
        • *smile* Decimal. It sure is a Bignum, isn't it? --MarkusQ
          • arg lol. i give up. i can get that num as binary: 10100000111010101110011011010000010000001110111011 01000011000010111010000111111 but then it's 79 chars long. i tried padding it to 80 bits with a 0 on the front, but the chars are out of range. same with a 4 bit char instead of an 8 bit char.

            • Yeah, 10100000111010101110011011010000010000001110111011 01000011000010111010000111111 looks about right. Let's see, adding a zero on the front gives 01010000 01110101 01110011 01101000 00100000 01110111 01101000 01100001 01110100 00111111 or 50 75 73 68 20 77 68 61 74 3F.

              Or just try:

              ruby -e 'n=379955903618604798669887;puts (1..10).collect {i=n % 256;n=n/256;i.chr}.reverse.join' --MarkusQ

  • The CVS book already mentioned will tell you how to setup a minimal server, if not google is your friend.

    Once the server is up and running your developers can import their own modules - you will just need to setup logins/passwords/SSH keys for them.

    Honestly little maintainance is required after that.

    The only things I've ever needed to do are:

    • Setup the server
    • Add new users.
    • Install cvsweb/viewcvs - for web based viewing of the repository
    • Ensure the archive is backed up on a nightly basis.
    • Make sure the

  • I've used CVS for about a dozen years with pretty good luck for a small community (~20) users on one project.

    Things that made life go better: encourage developers to do:

    1. cvs update after their grand upgrade of the source to incorporate other's changes in the interim; this avoids doing messy conflict resolution at commit time
    2. test your new version on all the test problems (it sure better compile at a very minimum)
    3. only then do the cvs commit with concise commit log message

    The repository stayed in pr

    • Aw, c'mon, branching is OK, especially in situations like fixing an old version of the code when the current top of trunk is not ready to ship.

      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.

    • Branching works. (Score:2, Insightful)

      by kupci ( 642531 )
      Do not branch. We never have but have heard of hair being pulled out when people do that.

      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.

    • Braches work and branching cannot be avoided if you have real life project with installed base of old releases that have to be supported.

      But you must be careful with the branches and understand how branching and merging work. Good idea is to write and to rigorously follow very hands down branching guidelines for your project with all the updates and -d's and -P's in place so that even the more experienced have no excuse for not doing it right ('oops, I forgot to cvs -xyz foo -bar').

      One thing I found out w
    • If you can build a script system to cvs export -D now a snapshot to do automated build testing and feature testing you and your developers will sleep better at night. Even better if you can do multiple platforms and show the results on an updated web page.

      We use CruiseControl for this. Works great.

      CruiseControl Home [sourceforge.net]

      There's also DamageControl. I checked it out, but got scared off by the need to install and use Ruby. I work with too many languages as it is, and am teaching myself Python, I don't need an

    • Do not branch. We never have but have heard of hair being pulled out when people do that.

      I had heard the same thing, so I stayed away from branching until I got here. We're a bunch of branching fools here, and it's actually not as bad as I was led to beleive. For the most part, CVS handles branching pretty well. The biggest area we had trouble with was figuring out how to specify branches in all the different tools (command line, Eclipse, wincvs, etc. etc.) that our people insisted on using. A couple o

  • BRL-CAD's has 20 years of CVS/RCS History (Score:3, Informative)

    by morrison ( 40043 ) * on Tuesday January 18, 2005 @02:42PM (#11398093) Homepage
    BRL-CAD [brlcad.org] is a very large scale project with over 20 years of history in RCS and CVS. The CVS repository [sourceforge.net] now lives on SourceForge with pretty much the entire revision history preserved (the project only recently released [slashdot.org] as open source). You can see one of the oldest files, for example here (bool.c) [sourceforge.net]. 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 [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.
  • There are several books about CVS. Oreilly publishes a nice one.

    My advice is to buy a book and read it.
  • 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

    If you've rarely used CVS properly, what makes you think it needs to be wiped clean and refreshed? I think you'd be better off recommending they get somebody who knows what they're doing to do a proper analysis of fixing it up.

  • Tortoise/IDE with built-in CVS support (Score:3, Informative)

    by SamNmaX ( 613567 ) on Tuesday January 18, 2005 @03:15PM (#11398532)
    Though this is on the client-side, it can be quite handy to use something besides the normal command-line CVS interface.

    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.

  • Best advice I can give... (Score:3, Insightful)

    by eviltypeguy ( 521224 ) on Tuesday January 18, 2005 @03:16PM (#11398545)
    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).

  • Don't use CVS! (Score:2, Insightful)

    by aquila78 ( 851048 )
    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.
  • You got a few pointers here but no one that commented seems to have run a larger environment - cause there you have very very different issues. Some of them sound trivial but in a 600+ people shop its the small things that kill you.

    First of, don't do symlinks even though they are possible... They always end up in a mess.
    Then make sure you provide them with a good way of changing their passwords (no matter what access method you're using) and see if you can't arrange it to force changes - otherwise people w

  • CVS standards I use (Score:2, Interesting)

    by MarkLewis ( 593646 )
    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
  • Get this book http://www.amazon.com/exec/obidos/tg/detail/-/0974 514004/104-4752216-1590345?v=glance

    It is very short but tells you 99% of what you need to know to use CVS.

    (as for all those \. ass-monkeys telling you to use Subversion -- sure, if your IDE of choice provides Subversion integaration to match its CVS integration. Eclipse (for example) doesn't.
  • Check out the Essential CVS book from O'Reilly: http://www.oreilly.com/catalog/cvs/ [oreilly.com]. It's concise and told me almost all I needed to know to manage my company's first CVS server for the last two years.

    Bonsai [mozilla.org] is the best tool I've seen for digging through CVS's not-so-friendly history output. It's web-based, and provides a nice interface for creating pointed queries to see who did what and when. The setup is a little bit arcane, but once you've got it going, it's very handy to have in your toolbox.
  • If your company can afford it, consider Perforce. If it cannot, consider a free revision control system that allows atomic commits (Subversion?). The company I work for went to Perforce and I am glad. The ability to group changes together, check in symlinks, and other niceties make this system great. Your entire CVS revision history can be imported to Perforce going back to the beginning of your project. In addition, the software is well documented.

    I am strongly considering using the free version of P
    1. What kind of company turns over their "decent sized" code repository to someone who has to ask slashdot how to administer it?
    2. Why are you wiping the repository clean and starting fresh? Who determined that would be necessary? You?
    3. If you are wiping clean, as others have suggested, see if switching to subversion will fly.
    Good luck, man!

Slashdot Top Deals

Anyone can make an omelet with eggs. The trick is to make one with none.

Close