×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

CVS Server Administration Tips?

Cliff posted more than 9 years ago | from the care-and-feeding-of-source-repositories dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

79 comments

The BEST CVS administration method (1, Interesting)

Omnifarious (11933) | more than 9 years ago | (#11397444)

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

Re:The BEST CVS administration method (1)

T-Ranger (10520) | more than 9 years ago | (#11397681)

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 (4, Informative)

tanguyr (468371) | more than 9 years ago | (#11397878)

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$

Re:The BEST CVS administration method (1)

bobbyjack (444724) | more than 9 years ago | (#11399700)

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 you were able to evaluate an alternative product whilst going with their recommendation at first.

Re:The BEST CVS administration method (3, Informative)

danpat (119101) | more than 9 years ago | (#11400328)

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 (1)

bobbyjack (444724) | more than 9 years ago | (#11400540)

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 :-)

Re:The BEST CVS administration method (1)

M1FCJ (586251) | more than 9 years ago | (#11400717)

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. easier to maintain and backup. I just cannot trust a disk/inode failure.

Re:The BEST CVS administration method (0)

Anonymous Coward | more than 9 years ago | (#11403529)

Does it or does it not depend on Apache 2.0? This is a deal breaker for me.

If you can use it without any extra dependencies, does anyone have a link to a HOWTO explaining how to do this?

Perhaps I'm missing something, but I've looked at Subversion a couple of times, but always got the impression I had to have Apache 2 running. Since I already run Apache 1.3 (and don't want them intermingled and don't want to create an IP alias for no good reason), I have stuck with CVS.

I'd love to be proven wrong here!

Re:The BEST CVS administration method (1)

Gilk180 (513755) | more than 9 years ago | (#11404521)

apache2 is not required.

There is a standalone svn server, but if your users have ssh to the server, ssh is probably the easiest option to deal with.

From the administrative point of view, there is another issue that I haven't seen mentioned that svn helps with. The whole thing is kept in a single file, so you don't have many of the problems with group ouwnership that cvs has. Creating a new file in the repository is just a db write, so there is no new file, where cvs would create a new rcs file, which would probably need its group changed before anyone can use it.

Re:The BEST CVS administration method (0)

Anonymous Coward | more than 9 years ago | (#11400405)

The biggest hitch I ran into when we were testing Subversion was that some on-site guys couldn't get to the repoistory because certain WebDAV things were blocked by the other companies firewall since they "reveal too much information about the local network." Switching to https fixed it though.

Beyond that we've had no real problems. It may be newer than cvs, but it's still years old.

Re:The BEST CVS administration method (2, Informative)

BigJim.fr (40893) | more than 9 years ago | (#11400512)

> 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, sure (1)

hey! (33014) | more than 9 years ago | (#11402346)

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 them. I'm going to be testing out SVN soon to see if the developers have an easier time. We an always go back.

Re:Well, sure (1)

42forty-two42 (532340) | more than 9 years ago | (#11402590)

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.

Re:Well, sure (1)

hey! (33014) | more than 9 years ago | (#11407609)

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.

Re:The BEST CVS administration method (1, Redundant)

mshiltonj (220311) | more than 9 years ago | (#11398215)

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!

Re:The BEST CVS administration method (0)

Anonymous Coward | more than 9 years ago | (#11398404)

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

Just add SVK [elixus.org] to that and you got a nice decentralized version control system.

Re:The BEST CVS administration method (1)

dozer (30790) | more than 9 years ago | (#11400504)

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.

Re:The BEST CVS administration method (0)

Anonymous Coward | more than 9 years ago | (#11403662)

I was just going to suggest this...

I switched to Subversion a while back and it seems much simpler to use; not to mention more intuitive.

Re:The BEST CVS administration method (1)

Hast (24833) | more than 9 years ago | (#11407893)

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 hosted projects (another added feature over SF is Wikis). AFAIK it uses the same system as SF so they are very similar.

Switch to SVN... (0, Redundant)

eWarz (610883) | more than 9 years ago | (#11397455)

1) Switch to SVN

Re:Switch to SVN... (1)

jilles (20976) | more than 9 years ago | (#11397612)

Yep, perfect opportunity to migrate. Test the migration on some machine until you are sure everything migrates properly and then flip the switch over night.

Nerd or Newb? (0, Flamebait)

Anonymous Cowherd X (850136) | more than 9 years ago | (#11397468)

Oh, come on, don't be lazy, Google is your friend. You want free advice for something you are getting paid to do and for which you do not want to spend a couple of hours researching and learning. Why was this question even approved? Is this news for nerd or news for lazy newbs?

Oh come on! (1)

Saeed al-Sahaf (665390) | more than 9 years ago | (#11397567)

Cut the guy some slack! Sure he can Google! But he's looking for nuggets of wisdom from all you experienced developer guys! Or perhaps you don't have any knowledge about this? Than maybe shut up.

Re:Oh come on! (1)

Anonymous Cowherd X (850136) | more than 9 years ago | (#11397828)

This isn't a Learn how to become a guru CVS admin in 21 minutes kind of site. Nothing you can tell him here will be a good enough substitute for real hands-on experience. That's why he needs to first research this on his own as best he can and then ask for advanced tips when he has a deeper understanding of the issues involved. So far he's only shown that he knows as much about CVS as anyone who is willing to spend 10 minutes reading up on it would.

Re:Oh come on! (1)

EnronHaliburton2004 (815366) | more than 9 years ago | (#11398017)

Nothing you can tell him here will be a good enough substitute for real hands-on experience.

Actually, we can point him to alot of good books and good reference websites, which is exactly what this thread is doing.

I'm in a similar boat-- relearning CVS so I can fix up our version control system. The Cederqvist is a good reference book, but it isn't a good learning manual, doesn't really talk about best practices.

With google, you still need to have a good idea what you are looking for before you look for it. If you just search for "CVS", you'll end up with alot of crud.

Re:Oh come on! (1)

bobbyjack (444724) | more than 9 years ago | (#11399848)

Although I agree with your general point (why shouldn't we help out here at slashdot!?), I must admit that CVS totally passed me by until I actually had to use the thing. It was a sharp, fast learning curve: if you learn to use it on an existing production project, I believe it will 'click' much faster than any background theoretical reading you might choose instead.

Re:Oh come on! (1)

EnronHaliburton2004 (815366) | more than 9 years ago | (#11401052)

It's a decent version control system, but it has wayyy to many quirks. After using other SCM systems, I'm really suprised at the things that CVS cannot do, and at all the workarounds to get around these quirks...

I used CVS years ago, then used Clearcase for several years, then used SCCS and RCS ...

I just came back to CVS, and I'm totally confused what needs to happen now ... What do you mean I can't version directories and symlinks. Is renaming a directory really that hard?

And I can't convert us all to SVN now ...

Re:Oh come on! (0)

Anonymous Coward | more than 9 years ago | (#11398189)

Anonymous Cowherd X: "Blaw, blaw, blaw, blaw, blaw, blaw, blaw, blaw, blaw, yap, yap, yap."

The reason we don't ask (4, Insightful)

Anonymous Coward | more than 9 years ago | (#11398405)

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.

Re:The reason we don't ask (0)

Anonymous Coward | more than 9 years ago | (#11399923)

Not sure about the "I hope that you never have children" (!) comment, but I don't understand why this hasn't been positively moderated AT LEAST once. Anyone get the impression that moderators stay away from ACs at ALL costs, even when they're making a good point?? Moderation is about rating the quality of the discussion, not about rewarding people.

Re:The reason we don't ask (1)

petard (117521) | more than 9 years ago | (#11434397)

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 no one ever posts garbage on /., so there is no need to sort the garbage from the good here. You should just unquestionably follow any tips you see here.

In that spirit, post your root password here. I'll help you get your CVS server running like never before.

Re:Oh come on! (0)

Anonymous Coward | more than 9 years ago | (#11401829)

This isn't a Learn how to become a guru CVS admin in 21 minutes kind of site.
But it is (apparently) the 'whine and bitch' site, or at least you seem to believe that it is. Believe it or not version control is a issue which is 'near and dear' to many, many developers, and is one of those topics which should be expored regularly in this forum.

Re:Nerd or Newb? (1)

xutopia (469129) | more than 9 years ago | (#11397588)

asking others isn't being lazy. It's being smart. What do you always ask google when asking other could save you valuable time and get you started with a better understanding of things?

Re:Nerd or Newb? (0)

Anonymous Coward | more than 9 years ago | (#11397647)

If my soon-to-be-CVS-admin only consulted Google, and didn't even try to get some answers from people who may have been in this same situation before, I wouldn't be very pleased with his performance. Would you?

Consider the source! (0)

Anonymous Coward | more than 9 years ago | (#11399622)

Judging by your posting history, Anonymous Cowherd X, it's clear you grabbed a new name due to shitty Karma. Go figure!

SVN... (0, Redundant)

M1FCJ (586251) | more than 9 years ago | (#11397677)

awww, I'm sticking my neck here, it can't be said enough times: switch to SVN.

A not terribly helpful, but still good, answer (0)

Anonymous Coward | more than 9 years ago | (#11397797)

Migrate to svn and learn how to use it. Sorry, but asking for pearls is going to get you nowhere unless you've got very specific scenarios to query against.

Cederqvist is the standard (1)

chjones (610558) | more than 9 years ago | (#11397850)

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 (4, Informative)

OmniVector (569062) | more than 9 years ago | (#11397851)

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 (1)

jrumney (197329) | more than 9 years ago | (#11399231)

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 on Windows machines is the SSPI authentication module for CVS NT (unfortunately also requires the server to be Windows, unless there is some hook into Samba to enable this that I don't know about), which gives secure transparent login to domain users.

Configuring multiple authentication methods will let you cater to remote users and those not logged into a Windows domain, but if your server is visible to the public internet, leave pserver off!

Re:cvs with ssh (0)

Anonymous Coward | more than 9 years ago | (#11408634)

Now all your cvs users can do harm to the repository (on purpose or otherwise) via ssh, since they are members of the cvs group.

Am I wrong? Is there a way to (a) have people access cvs via ssh and (b) make sure that they can only access the repository through the cvs command set (or can only run cvs command set on the cvs server)

Re:cvs with ssh (1)

OmniVector (569062) | more than 9 years ago | (#11410698)

rssh i think does cvs-only over ssh. there's a major security hole in rssh with chroot right now, but you're fine if you don't use the chroot feature.

Re: Your sig (1)

MarkusQ (450076) | more than 9 years ago | (#11426898)

379955903618604798669887 --MarkusQ

Re: Your sig (1)

OmniVector (569062) | more than 9 years ago | (#11432629)

how's that encoded?

Re: Your sig (1)

MarkusQ (450076) | more than 9 years ago | (#11445556)

*smile* Decimal. It sure is a Bignum, isn't it? --MarkusQ

Re: Your sig (1)

OmniVector (569062) | more than 9 years ago | (#11448777)

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.

Re: Your sig (1)

MarkusQ (450076) | more than 9 years ago | (#11463039)


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

Little admin required .. (1)

stevey (64018) | more than 9 years ago | (#11397875)

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 disk doesn't get too full!

More specific questions might help, but really CVS is a low-maintainance tool. Once it's setup it just keeps working.

Be sure you're not exposing it externally if you're not needing to and make sure you track security updates via bugtraq/the CVS homepage and you're done.

Do Not Branch; Backup the Repository; Test Always (1)

4of12 (97621) | more than 9 years ago | (#11397948)

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 pretty good shape, even after we manually hacked files in the CVSROOT directory instead of doing what we were supposed to do and checkout and checkin changes to files in that directory.

Occassionally, we'd have problems with users of the "wrong" group id checkin and make it hard for others to check out. That problem might be fixable with a sgid sticky bit on the repository directory. We even limped past the Y2K thing with an old version of CVS that tells people that it's 19105 right now.

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

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.

Occassionally it's good to tag a release. A major bump in the release number helps morale, too.

CVS does work, but I'm seriously looking into subversion for my next repository.

Re:Do Not Branch; Backup the Repository; Test Alwa (2, Insightful)

Control-G (793543) | more than 9 years ago | (#11398808)

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.

Re:Do Not Branch; Backup the Repository; Test Alwa (0)

Anonymous Coward | more than 9 years ago | (#11398880)

i agree with the "backup the repository and test always" mantra but clearly not the "do not branch" part of it. I think that you will be missing an important aspect of CVS. Branching is a must for multi-team projects - specifically when they are independently developing different product features.

Branching works. (2, Insightful)

kupci (642531) | more than 9 years ago | (#11403374)

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.

Branches Are a Must (and XP/Agile learnings) (1)

upm (112839) | more than 9 years ago | (#11406635)

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 when doing XP (Agile nowadays?) style development was that it is good to use very short lifespan on most branches i.e. use temporary branches for each implementation unit and merge the changes to the development branch when the unit is finished.

Long lived branches should be used when updating old and developing new releases, one per release.

The temporary braches should be really temporary with lifespans as short as 30 min and never leave them hang around to the next day.

Of cource the standard XP practice of running unit tests each time you build running "make" or "ant" and passing them all before you "commit" the merge is also quite recommendable.

It is also a good idea to require all working in the same release branch to update each time a merge (or "integration" in XP) is done.

Re:Do Not Branch; Backup the Repository; Test Alwa (1)

boodaman (791877) | more than 9 years ago | (#11412421)

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 another especially just for one tool.

Re:Do Not Branch; Backup the Repository; Test Alwa (1)

computational super (740265) | more than 9 years ago | (#11431748)

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 of things that we've learned the hard way, though:

  • If branch B was created from branch A, merge branch B back into branch A. Do not merge branch B into branch C, D, or any other branch. Ever. Trust me. Or don't trust me, and regret it.
  • Create as few branches as you can get away with. We have a nasty habit here of creating a new branch each week, per project (project being used in the marketing sense of the term). It's been a tad bit of a nightmare to keep track of all of those branches (nothing's quite as frustrating as commiting code to the wrong branch and having to manually re-do the work on the right branch).
  • Read the CVS Faq (not just Cederqvist) from the source directory - especially the part that talks about tagging before branching (I think they refer to these as branch-point tags). It's an easy thing not to do, and something you'll regret if you don't (Subversion has been mentioned here several times - one of Subversion's finer points is that branchpoint tags are not necessary).

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

morrison (40043) | more than 9 years ago | (#11398093)

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.

Re:BRL-CAD's has 20 years of CVS/RCS History (1)

Lukey Boy (16717) | more than 9 years ago | (#11401339)

I would have been more impressed if the 20 year old file was not in the Attic :-)

Re:BRL-CAD's has 20 years of CVS/RCS History (2, Informative)

morrison (40043) | more than 9 years ago | (#11403424)

Actually that file does still exist. It's here [sourceforge.net] now. Less than a year ago, the package went under massive directory reoganizations. CVS commit comments on the old and the new tell you where things came from and/or went to (and is in the CVS policy). If you want to see one not in the Attic with some age, the README [sourceforge.net] will take you back almost 18 years or so.

Why refresh? (1)

CMU_Nort (73700) | more than 9 years ago | (#11398437)

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 (2, Informative)

SamNmaX (613567) | more than 9 years ago | (#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... (2, Insightful)

eviltypeguy (521224) | more than 9 years ago | (#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).

Re:Best advice I can give... (1)

mangino (1588) | more than 9 years ago | (#11399007)

Make sure you disable all access to cvs during backups, and make sure there are no in-flight changes. You'd hate to get an incosistent backup!

Re:Best advice I can give... (1)

engywook (802813) | more than 9 years ago | (#11399090)

If you are not "allowing pserver access at all", why do you need to worry about the userid of the CVS server? It seems to me that there's no reason to even be running the server if you aren't allowing pserver access. I've never run it on my CVS servers.

Re:Best advice I can give... (1)

eviltypeguy (521224) | more than 9 years ago | (#11414668)

What part of Trust No One didn't you read? :)

SSH is just good for security of login information anyway.

use SSH (0)

Anonymous Coward | more than 9 years ago | (#11398789)

ditto the previous poster who said "use SSH". The only way to access the server should be via SSH. Every user who needs write access should be in the "cvs" Unix group. The directories should be set so they get owned by that group. That will make things simpler AND eliminate security problems.

This goes for Subversion too (I don't really get excited about subversion, it just seems bloated and overengineered inside). Use the apache module over HTTPS or use SSH.

Also, learn how to get the logs out of CVS (cvs history). That's something you'll need to do a lot. I can hardly ever remember the flags though.

Someday you might also have to break a lockfile (subversion fanboys: berkeley DB gets wedged too. and when it does it's worse.) or do backups... you'll learn that when you need to.

For books, try the O'Reilly CVS book. It's not written very well but it has all the information you need. There is also the Pragmatic Programmers guide but that's suited more toward users than admins I think.

Don't use CVS! (2, Insightful)

aquila78 (851048) | more than 9 years ago | (#11399202)

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.

Symlinks and others... (1)

loony (37622) | more than 9 years ago | (#11401943)

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 will share ids and its a pain.
If nessecary, create functional IDs - that way you at least know its not one person but a group.
Keep cvs on a Tru64(advfs) or Linux box... HP-UX or Solaris is a lot slower... solaris10 with zfs might be close but haven't tried that yet.
Look for a few frontends (like cvsweb and so on) - they will help a lot for users that are new.
Send out an email with the cvsbook link (link is on cvshome.org) and make sure you remind people that's a good reference.
Offer them wincvs - windows users will not only have trouble adapting to command line but will screw up bigtime and after all its your job to fix it...

Peter.

CVS standards I use (2, Interesting)

MarkLewis (593646) | more than 9 years ago | (#11403148)

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.

Buy 'Pragmatic Version Control using CVS' (1)

Tom Davies (64676) | more than 9 years ago | (#11403666)

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.

Re:Buy 'Pragmatic Version Control using CVS' (1)

His name cannot be s (16831) | more than 9 years ago | (#11407754)

as for all those \. ass-monkeys telling you to use Subversion

heh-heh. Ass monkeys. You're funny.

Pity you don't know about subclipse [tigris.org]

Eclipse has had subversion support for quite a while.

Essential CVS and Bonsai are a big help (1)

leono (76178) | more than 9 years ago | (#11403854)

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.

Consider Perforce (1)

ufnoise (732845) | more than 9 years ago | (#11405282)

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 Perforce for my home projects.

This is wrong on so many levels (1)

lorcha (464930) | more than 9 years ago | (#11407537)

  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!

check out OpenCVS, another one by the OpenBSD team (0)

Anonymous Coward | more than 9 years ago | (#11408657)

http://opencvs.org/
It fixes some annoying problems with CVS, and benefits from additional security as well.
I haven't used it yet (waiting for release) but I'm looking forward to that day!
No need to switch to another revision control system, just fix the old dog so it works the way it's supposed to. :)
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...