Given that Subversion has basically been written to replace CVS, are there any compelling reasons at this point to continue using CVS for version control?
+8
A:
Yes, if you're part of a larger organization that's reluctant to change.
If you're asking whether it would be good to choose CVS as part of a new installation, I can't think of a good reason. Now I think the choice would come down to SVN or GIT, and the choice would depend on which fit better into your organization's development strategy.
duffymo
2009-06-04 02:04:51
One reason might be tools integration. CVS is usually well supported in all modern IDE's, but subversion or git might not be (just look at Eclipse).
Thorbjørn Ravn Andersen
2009-10-25 18:22:20
All three are supported by IntelliJ (just saying). I know that Eclipse certainly supports Subversion right now (Subclipse plug-in).
duffymo
2009-10-25 22:26:03
+2
A:
I would turn that question around. Are there compelling reasons to switch to Subversion? We use CVS and it works fine for our stuff. There's no business benefit at all that we can see for switching.
As with all decisions, it should have a cost/benefit analysis done to see if it's worth it. Your question doesn't give us enough information to help you out there.
paxdiablo
2009-06-04 02:06:44
If you rename files (Java refactoring comes to mind) you will like SVN, as it preserves the history of the file and is able to restore the previous directory structure if you check out an older version. CVS lacks that feature, as it only versions files and not directories.
lothar
2009-06-04 02:09:36
Okay, good, if you rename or move files, SVN is better - that's a good start to your cost/benefit analysis [cost = effort to change, benefit = that one (plus others no doubt)]. The question still remains: is the benefit greater than the cost?
paxdiablo
2009-06-04 02:18:52
YMMV, but at least for us SVN was considerably faster than CVS when updating and commiting.
Badaro
2009-06-04 02:26:52
@Pax I agree that if it works for you there's no benefit in changing. The old "never change a running system" idiom. But "works for me" is hardly a generic argument for it's use either ;-)
lothar
2009-06-04 02:30:24
In referential integrity alone, CVS is worth the cost to upgrade. It's command-compatible, there's no end-user learning curve (except working-copies).
Chris Kaminski
2009-06-04 11:52:47
+1
A:
There is only one good argument I've heard in favor of CVS, and that is in situations where you have a project that will have many different releases and branches, in CVS it is easier to just push an arbitrary file into the branch or tag you need when you need it. SVN is more formal about these things, and makes it harder to just pick on one file and merge it as you need it. It is a dangerous thing, but like direct memory pointers, sometimes you just need them.
That being said, if CVS is already in place, that may be a different story. There the calculus is is there a benifit in switching. One might be that SVN gives you better ability to code on your laptop disconnected from the office. You can schedule files for adding and deleting, and you can check that in when you get back to the office.
Some organizations wouldn't dream of letting their developers out with the source code on their laptop, so this doesn't apply to them.
My view is that SVN should be your default choice for new projects. It is mature, its tool support is as good as CVS, if not better in some cases, and doesn't really have any important deficiences over CVS.
That being said, GIT is up and coming. It still a little immature (for example Windows support hasn't hit the mature stage) and the tool support is still catching up, but if distributed branching is important to you, it is worth taking a good look.
Yishai
2009-06-04 02:13:52
"In CVS it is easier to just push an arbitrary file into the branch or tag you need when you need it" - Ouch that hurt! Why do version control in the first place when you want to circumvent it?
lothar
2009-06-04 02:15:59
@lothar, as I said, its dangerous, but say you have to have a fix in a certain branch for a certain version in the possession of one customer, and you want to make sure that nothing else changes. Specialized case, for sure. If you have a code base sold to specialty customers one at a time, it may just come in handy.
Yishai
2009-06-04 02:42:23
svn makes editing arbitrary branches simply and easy, and a branch in SVN is a zero-copy effort. Not so in CVS, and I'd NEVER want to make such a one-off type fix to a branch in CVS. CVS was GREAT, when it was an improvement on RCS. But 1994 was 15 years ago, and it's time to move on. The world has gotten more complex and dangerous. :-)
Chris Kaminski
2009-06-04 11:57:01