CVS vs. SVN vs. Everything else - version control methodologies.

#1 Subversion is a newer implementation and has some features that pertain to handing binaries that make it a little better than CVS.

Either of these source control methods will enable you to have an audit trail during development.

the use of Tags and branches is at times critical for simplifying the ability to utilize the audit trail.
this will allow you to protect the source code from mistakes.

tortoisesvn.tigris.org/

here is a client that is simple to use.

#2 Technically and from a user perspective, there's a lot to be said against Subversion, but while there are some awesome new revision control tools around (Monotone particularly impressed me) what often makes their use impractical or at least highly cumbersome is the lack of tool support--which by now Subversion has (IDE and system integration).

If, however, you are willing to shed out some bucks on this, then there's *far* better alternatives to Subversion. I personally have yet to find something that beats Perforce, but its workflow and price point definitely isn't for everyone (the latter wasn't for me either; I only used the non-commercial license).

As for methodology, in a tightly synchronized setup of 6 programmers working on a project, Subversion will definitely do the job--though you probably may find yourself swearing about some of its peculiarities from time to time.

#3 We use Subversion (SVN) over CVS as CVS has even more peculiarities then SVN. We use it for our games and I have implemented it in all the companies that I have worked for when developing software for them.

SVN has powerful features including Apache support (which allows you to check in files via HTTP hence bypassing some of the firewall issues you may encounter and it allows you (if configured this way) to browse the repository via a web-browser.

There are a host of Windows, Linux, and Mac UIs for SVN and most of this provide shell integration into the OS (i.e. Right-Click -> Commit to repository). SVN doesn't enforce business workflow but there is a process to be followed in order to checkout, create, update and commit files ... these processes however are not complicated.

I have successfully used SVN for Windows development, Java development, Web-based development (PHP, ASP, JSP, HTML), and Torque projects ... I have even used SVN as a document management system and still use it to back up my home directories on my WIndows and Linux laptop ... :)

In short, it is versatile, it does not have the problems that CVS does and it is OpenSource. :)

#4 I haven't tried it yet but the Bazaar distributed version control system might be worth a try.

#5 One of the best features of SVN over CVS that was not mentioned here is transactions. A commit can fail half way through in CVS and you will have half the files in and half not. Subversion is all or nothing, this can be a nice feature if you are working remotely and have the possibility of losing connection during a commit. Perforce has this feature as well.

#6 Every once in a while (usually when I start a new project), I revisit version control. I recently switched from CVS to Git. Since most of my projects are one-man, Git is worked out really well for me. It was a fast and simple setup. I'm not sure how useful it is in a multi-user environment, but from what I've seen so far, I can only assume it would work fine.

#7 In addition to SVN and TortoiseSVN, you have also a great plugin for VisualStudio : AnkhSVN (ankhsvn.open.collab.net) : easy to use and perfect integration in VS.

#8 From what I've heard so far - it sounds like SVN would work best for this project. I do have a follow up questions though:

Our programmers are geographically scattered - and we may have times when people will be out of contact for a while. Would SVN still be the way to go in this case?

#9 We use TFS (Team Foundation Server). It's Microsofts newest version control, bug tracker, project tracking (etc) SDLC system. We currently enable concurrent checkouts, but I personally hate that and recommend to turn it off (one person at a time, please). It's incredibly customizable.

#10 From what I've heard so far - it sounds like SVN would work best for this project. I do have a follow up questions though:

Our programmers are geographically scattered - and we may have times when people will be out of contact for a while. Would SVN still be the way to go in this case?

#11 SVN works great for me (in Norway) and a partner in crime (in the UK). It IS tricky and old-fashioned in the way it does authentication, though. I am looking at other systems for solo (iPhone) projects, as some features of XCode makes it necessary to drop to a command line for updates anyway. I don't really use IDE integration.

#12 Yes SVN would work but just like most other version control systems it is better to make frequent small updates rather than rare large ones. If you have a server setup somewhere then all everyone would need to do is commit their changes once a day or so. The internet works everywhere so it makes no difference where they are.