«    »

My Experience with Subversion

Subversion is open source version control software that has significantly gained in popularity over the last few years as a replacement for CVS. I have been using Subversion for a while for my personal projects at home. It has generally worked well, but I have encountered a few difficulties along the way.

One reason I like Subversion for personal use is that you can use it without running the server. The repository can be stored on your local file system and accessed by a Subversion client directly. To effectively use version control, I believe a graphical user interface is a necessity. Subversion only comes with a command-line interface that is great for automating builds, but insufficient for daily use. Fortunately, there is a great Windows SVN client called TortoiseSVN which integrates beautifully with the Windows Explorer shell.

As a Java developer, I've been spoiled by the exceptional CVS support in the Eclipse IDE. As good as TortoiseSVN is, it doesn't compare to having version control capabilities integrated into the IDE. Eclipse CVS support especially excels at doing difference comparisons and merges. So I was quite happy when I came across Subclipse, an Eclipse plugin for Subversion. I've only been using it for a short period of time, but its been great so far - just like Eclipse's CVS support. I've been able to use both Subversion clients on the same local workspace which I like since I can fall back to TortoiseSVN if Subclipse is missing functionality I need.

Setting up a Subversion repository is easy, but has a hidden catch. As with all version control systems, the first step is to create your directory structure with files that you want to version control. The obvious next step is to use this structure to create your repository. This will work for a while until you try to create your first tag (or branch). Then you'll discover you have nowhere to store the tag. Subversion treats tags and branches as simple copies of an existing directory structure that are themselves stored in the repository. To accomplish this, the Subversion documentation recommends setting up three root directories: /head, /branches, /tags. Let's assume your files to store in version control are all contained in a directory contained /projects. This would be stored directly under /head as /head/projects. If you create a tag called release-1.0, the corresponding version of your files would be stored under /tags/release-1.0/projects. If you have already set up your repository without this structure, it is easy to fix. Using the repository browser in TortoiseSVN, you can create and move directories directly in the repository, and these changes are themselves versioned so you can easily undo the change if necessary.

One issue I have with Subversion is that it creates .svn directories in each versioned directory for tracking the state of your local workspace. Version control software must store this information somewhere: I'd prefer to see it stored separately. On Windows, a logical choice would be an user's Application Data directory. Storing the .svn directories within the local workspace directories causes a few problems.

The main issue is renaming directories: if you don't use the Subversion client to rename a directory from /foo to /bar, then the new /bar directory will have a .svn subdirectory that thinks it is still directory /foo, and the Subversion client gets confused. In Java development, this is a problem when you want to rename a package. Using Eclipse to rename the package changes both the directory name and all the java files within the directory at once, but you need to notify the subversion client as well. If you are using Subclipse, then this happens automatically when you do the rename in Eclipse so there is nothing to worry about. If you are not using Subclipse, then it becomes a multi step process. First use TortoiseSVN to rename the directory, which updates the .svn directory contents. Then manually rename the directory back to the original name and use Eclipse to rename the package back to the new name, which will update the java files. Now both the Subversion local workspace and the java files consistently refer to the new name.

Another issue with storing .svn directories within the local workspace is that it becomes difficult to do manual operations on the local workspace. For example, if I want to set up a new Java project, the easiest way is to copy an existing one and then delete what I don't need. But if I do this, I'll copy all the .svn directories and confuse the Subversion client. If you want to zip up your workspace, it will by default include all the .svn directories and be roughly double the size it would otherwise be. One workaround for this problem is to use TortoiseSVN's export command which checks out files from the repository without creating a local workspace, which means that the .svn directories are not created, and that you cannot check in changes from these files since they are no longer connected to the repository.

Overall I am quite happy with Subversion, especially when used with the Subclipse plugin in Eclipse. If you use Subversion, what have your experiences been like? Any tips, tricks, or pitfalls to pass along?

If you find this article helpful, please make a donation.

4 Comments on “My Experience with Subversion”

  1. Rob Williams says:

    Subversion recommends creating a “trunk” directory, rather than “head” (very different semantics), and a lot of other tools depend on this.

    Subversion is essentially CVS 2.0, so it is fundamentally the same in that it uses a private subdirectory (.svn versus CVS) for its bookkeeping. Some of the newer source control tools (distributed version control systems = DVCS) have designed away from this issue. I am moving away from Subversion (my previous favorite) to Bazaar because of the many design advantages.

    The need to export, and the need to carefully orchestrate multiple tools (source control client and IDE) are not problems that require “workarounds”. Export is a built-in feature for handling the use case of producing a copy of the content without the bookkeeping, for both CVS and Subversion. Integrating source control into an IDE is not the responsibility of the source control tool–that squarely lies on the shoulders of each IDE.

    The former (export) is an inherent characteristic of the design. The latter (renaming/moving source files) is an inherent characteristic of using IDEs with source control.

    If one subscribes to the IDE paradigm, then one is motivated to find a pre-integrated source control client for their favorite IDE(s). If one does not subscribe to the IDE paradigm (choosing simpler, non-integrated tools), then one can avoid the “problems”, and the extra work, altogether.

  2. Good points, Rob. I agree that issues like needing to use export and IDE integration are not problems with Subversion itself. I do feel, however, that these are issues regarding the use of Subversion that developers need to be aware of.

  3. Jeffrey says:

    “One reason I like Subversion for personal use is that you can use it without running the server. ”

    This is true for cvs as well. The cvs implementation inside eclipse seems to support only client-server mode, but that is eclipse’s issue, not cvs’. The true cvs command-line version supports accessing repositories on the local filesystem without the server.

  4. [...] found somewhere that I should do it in many steps to prevent incoherence between content of .svn folders and [...]

«    »