NNDK 2.6.0 CVS gone?

[zealott]

CVS anyone?

Thanks

[dciliske]

What are you asking about? Complete sentences help.

[tod]

I prefer Rite-Aide myself. Or you might be talking about source code control in NBEclipse. If the plug-in for CVS is no longer included, you'll probably have to switch away from NBEclipse to a more generic release of Eclipse (Indigo would be my recommendation). Then you can install whatever SCM plug-in you want. You might want to consider looking into Mercurial(Hg). I wrote up ablog entry on how easy it is to use and some of the benefits. I use the MercurialEclipse plug-in to make life even simpler from within Eclipse.

[dciliske]

Apologies for my brusqueness; I thought this was in the general software section. I guess that's what I get for browsing the "Active Topics" section without paying to much attention to which section it's in.

Seconding Tod's point, I would highly recommend to moving to a newer VCS/SCM, specifically a Distributed Version Control System (DVCS). Tod uses Mercurial; we use Git internally (we switched back in March). If you would like to stick with CVS I would follow Tod's advice of using a more generic form of Eclipse.

CVS is unfortunately a very weak version control system. The one good thing it does, is give you concrete version numbers for a specific file; everything else it does poorly.

The straw for us was when I (who had never used CVS before arriving (I'm a young whippersnapper you see)) learned that CVS does not group commits into a single item. This means that when you have a feature or a bugfix that touches multiple files and commit them all at once, CVS logs each file seperately. It gives you no way to find what other files where modified at the same time as the new bug you discovered 4 months later.

There's also the fact that, for most practical purposes, CVS cannot branch; while technically true that it supports branching, the merges at the end are usually so painful that it is rarely utilized for small to medium sized changes. This leads to you rarely checking in while developing a new feature. Contrasting this with either Git or Mercurial (or really any DVCS) and you'll find that branching and merging are absolutely trivial. I normally have three or four active branches in my dev environment at any given time, and can seamlessly jump between any of them with ease.

A final note on DVCS's is that you can do local commits to your repository. One of the biggest issues when developing a feature is that you don't want to commit anything into the master branch of the central server that's not finished or is buggy. This usually means that a feature or change is only committed once it is completed. This is ok for two hour jobs, but not for multiple day or multiple week ones. The potential for lost work is too high. By using a DVCS, you have a local copy of the repository, with full revision history that you can commit to. Only when you're finished do you need to actually commit to the central server. This also means that backing up a DVCS is part of every developer's workflow, as every time they pull the latest version from the main server, they now have a complete copy of the repository.

I'll say this however, DVCS's take some getting used to. We're 8 months in and some of us are still learning how to use the more advanced features or features unique to DVCS's, but it has absolutely been worth it.