Using Subversion for your open source project

Subversion has been an open source contribution by CollabNet folks which improves over CVS. The Subversion project started in earnest in February 2000, when CollabNet offered Karl Fogel a full time job developing a replacement for CVS. Karl Fogel and Jim Blandy had previously founded Cyclic Software which provides commercial support for CVS. Subversion was designed from the ground up as a modern, high-performance version control system. In contrast to CVS, which had grown organically from shell scripts and RCS, Subversion carries no historical baggage. Subversion takes advantage of a proper database backend (Berkley DB), unlike CVS which is file based. The Subversion team have tried to make the new system similar in feel to CVS, so users are immediately at home with using it. Most of the features of CVS including tagging, branching and merging, are implemented in Subversion, along with host of new features:

• versioning support for directories, files and meta-data
  
• history tracking across moves, copies and renames
  
• truly atomic commits
  
• cheap branching and merging operations
  
• efficient network usage
  
• offline diff and revert
  
• efficient handling of binary files

Salient points about Subversion:

• Subversion is a centralized client-server version control like CVS, VSS or Perforce.
• Advanced network layer: the Subversion network server is Apache, and client and server speak WebDAV(2) to each other. This gives Subversion an advantage over CVS in interoperability, and provides various key features for free: authentication, wire compression, and basic repository browsing.
• It's free: Subversion is released under an Apache/BSD-style, open-source license.
• Like CVS, Subversion has a concept of a single, central repository (often residing on a dedicated server) that stores all data about the projects you are working on. This data is called a repository. You never work in the repository directly, though. Instead, you pull subsets of it into working copies that typically reside on other systems such as your desktop computer. In these working copies, you make your changes, and when you are pleased with them, you commit those changes into the central repository where they become once and forever part of history.
• Each commit (also called a check-in) to the repository is called a revision, and, in Subversion, revisions are numbered. A commit can be a change to one file or a dozen, to directories, or to metadata.
  
• We speak of HEAD when we mean the latest version of the repository; so, when you check in revision 17, then HEAD is revision 17.
• Atomic Commits: In Subversion, a commit is an atomic operation, meaning it either succeeds entirely or fails entirely; unlike CVS, you can't end up with half of your files saved to the repository but the other half unchanged.
• Not only does Subversion offer version control of files and directories, it also offers version control of metadata. In the world of Subversion, such metadata is called a property, and every file and directory can have as many properties as you wish. You can invent and store any arbitrary key/value pairs you wish: owner, perms, icons, app-owner, MIME type, personal notes, etc. This is a general-purpose feature for users. Properties are versioned, just like file contents. And some properties are auto-detected, like the MIME type of a file (no more remembering to use the -kb switch).

To read about a quick intro to the setup of a local subversion repository (ie svnadmin create) and how to use the basic svn client commands (checkout, status, commit, update, log, diff, mv, rm, merge, stat, up etc) read this article by Chip Turner. The complete manual for different subversion releases are available too.

If you already have worked with CVS, and you have the option to choose a SCM tool for your project then its better to start with Subversion as it improves upon CVS in several ways. Also the client commands are similar to CVS thus enabling easier migration. Several tools/scripts/IDE plugins/GUI Clients for subversion are now available and mentioned here. Google Code free project hosting and collaborative development site, uses subversion as its version control server.

I have been introduced to subversion in one of my project works in the year 2004 at Hewlett Packard. HP used CollabNet for most of its projects for collaborative development across HP sites and we used to use the Subversion client Tortoise SVN which integrates with Windows explorer. Back then the tortoise svn was still not stable enough and made the particular working directory (copy of the repo) in windows explorer very slow to navigate. So we mostly used the command line client then. For BaseApp, i chose google code project hosting service as it seems to be the most intuitive and easier to get started with than sourceforge.net. Google code project hosting service provides a issue tracking service and a SCM service. Google also provides free discussion forums for your projects from its Google groups. So, with BaseApp, i am back to using Subversion (and this time around i hope the GUI clients will be helpful and not make me go back to command line tools).