Believe it or not, this article is not going to be about how bad VSS is.  I've been using VSS since version 1.0, that's before Micrososft bought the product.  And while I've seen all kinds of complaints about how VSS corrupts the data, I've never experienced the problem.  There have been other quirks I've had to deal with concerning IDE integration.  But, data corruption, when it occured, was not a VSS problem.  For those who are currious, it was a MacroMedia problem.  No, the reason for the switch is more pragmatic.  The primary reason I moved to SubVersion is because it allows me to use my computer from anywhere without a whole lot of trouble.

Disconnected Version Control

For those of you familiar with the VisualStudio 2003 environment, you are already familiar with the fact that Microsoft added a feature in VS2002 that allows you to work in "disconnected" mode if you are unable to connect to VSS (or whatever your repository is) however, I can tell you that my experience working in disconnected mode has always resulted in VisualStudio thinking files are out of sync when they aren't.

In SubVersion, disconnected mode is the default.  In fact, the only time you ever connect to the server is when you need to retrieve most recent versions (update) or send your changes up (commit).  If I want to edit a file, I don't even have to be connected to the network.

Speed

The first time I added a project into a SubVersion repository, I was absolutely amazed at how little time the operation took.  It's just a guess, but I think the same operation in VSS would have taken three times as long.  And updates/commits of changed data are super fast since only deltas get transferred.  There are several of us who have attempted to force VSS to be a delta based system of sorts, but why not just use a version control system that works that way natively.

Auto Merge really works

OK.  I promised not Microsoft bashing.  But, I have to admit, VSS multi checkout always made me just a bit nervous.  Especially using a tool like VSS.NET.  If there was a merge conflict, how is the client suppose to know about it?  This, of course, should work well if you are using standard VSS.  But, I've met very few programmers that were not more comfortable with single checkout.

Probably the hardest thing to get use to about SubVersion is that file locking is an option, not the default.  SubVersion, and many other version control systems use an "Edit/Commit" model vs a "CheckOut/Edit/CheckIn" model.  With Edit/Commit, anyone can make a change to any file at any time, even if someone else is making a change to the same file.

If you've used VSS for as long as I have, this can really make your head spin.  I can hear the old timers now, "So, if I make a change and someone else is making a change, how does the repository keep track of all that and put the files back together in the repository?"  We'll here's how it works.  Let's say Bob and Joe are working on a project and the boss assigns each of them a bug to work on.  It just so happens that each bug requires a change to the same file.  So, Bob and Joe bring up the file in their editor and start making changes.  Most of the time, in this situation, Bob and Joe will make changes to the same file, but they will not make changes to the same lines in that file.  Joe finishes his bug first and commits it to the repository.  Since he's the first one to commit the change, it just goes in like he was the only one working on the file.  Bob finishes his change sometime later.  When he commits, SubVersion will tell him that the repository has changed since he made his changes and that he needs to "Update" his file.  So, he issues an update command which brings the file down from the repository and merges the changes with his current file.  Once the changes have been merged into his file, he can commit the file.  This worked so well the first time I did it, I thought I had done something wrong.

In the rare case where SubVersion can't figure out how to do the merge, subversion will produce three files.  The file that represents the current revision, the file that represents your changes, and a file that represents the original you started with.  It is your responsibilty to figure out how to merge the files using a diff tool.  I was in a position once where I had to do this, but I was still so new to SubVersion that I didn't know what I was suppose to do.  So, I don't have any real experience with this feature yet.

There is one note, for those of you who might also make the move to SubVersion.  The latest version now supports file locks.  Make sure you implement these for binary files.  SubVersion does merges of text files pretty nicely, but a merge of a binary file, like an image, isn't going to work, and there isn't a visual merge tool in the world that is going to help you.  Better to lock the file before making the change.

Separate Repository for Each Project

Under VSS, it was possible to have one repository that held multiple projects.  This is because each file got it's own version number.  Most of us generally used this method because setting up a new repository in VSS took a bit more time than most of use would like.  Create the database, add the users, etc.  It wasn't hard.  It's just that it is easier in SubVersion, the way I have it set up.

Under SubVersion, versioning is on the whole repository, so you are going to want to create a new repository for each project.  While this might seem odd to you at first, think of this as "auto labeling," ie, if you want to get the code from a particular time in the history of the project, all you need to do is update, or export, from a specific version and you have the snapshot of the project at that point in time.

It Works on Windows

Back at the beginning of the dotCom era, when I initially needed a client/server version control system.  I looked, very briefly, at using CVS.  While CVS seems to be a very good solution, it's chief problem for me was that it really wanted to be installed in a 'Nix box.  While I've played with Linux off and on for almost 10 years now, when I needed the client/server version control solution I was not even close to the point in my understanding of Linux security to be able to install CVS.  I don't know if it's changed since, but at the time, CVS used the operating system's authenticaion to control access, which I was also not real fond of.  Set up access incorrectly for one of those users and I knew I was just asking for trouble.

In contrast, SubVersion works on Windows and, while authentication can be tied to the operating system if you want, it is not required.

It's FREE

Yep.  It's an open source project and you can get it now.  I'll be writing a full article later on how to set it up.  But, for the impatient, here are some tips that will save you a lot of time.

Tips

• Do not use the SSH configuration, especially if you are using Windows 2003 server as your server.
  
  This looked like the best implementation to me.  But, so far I have not been able to find an SSH server that works on 2003 completely.  The closest I've found so far is freeSSHd, but it doesn't impersonate the logged in user using local users.  I've heard it does impersonate correctly if you are using domain users.
  
  
• Use WebDAV with Apache 2.0
  
  I know, this probably seems like you are being a traitor.  But hey, you've already jumped into the Open Source pool, using Apache isn't going to kill you.  If you need to have IIS running also, you can run Apache on a separate port and access the repository by specifying the port number at the end of the domain:
  
      http://yourdomain/subversiondirectory
  
  There are some added advantages to using WebDAV other than the fact that it is the only way I was able to get this working under Windows over the Internet:
  
  
  1. Authentication is separate from Windows authentication, but you have the option of tying it to Windows authenticatoin if you want to.
  2. There is a feature called "auto versioning" that allows you to copy files from version control to your working directory.  Make changes, and then copy them back.  The commit cycle happens for you.
  3. WebDAV will work with MacroMedia without using any external software.
     
     
• Commands
  • Update - similar to a VSS Get command.  Brings down the data from the repository and merges any changes with your current files.
  • Commit - similar to a VSS Check In command.  Puts your changes into the SubVersion repositiory.
  • CheckOut - retrieve a project out of SubVersion so that you can start working on it.  This command ONLY works on empty directories.  If you are in an organization and you are moving from VSS, you'll want to have one developer create the project in your repository and then all of the other developers will CheckOut the project to an empty directory on their local computer.  At that point, they can either copy the files into their regular folder or copy the newer files from the old project folder to the new one they just created.  To be safe, I always name the new folder with the same name as my existing folder.  I rename my exising folder if I have to.  That way, any directory information that may be tied to the folder when I do the CheckOut, won't get everything confused.  I don't know that this is a problem, but it's a simple way of ensuring I don't have any problems.
  • Import - this is the command that gets the project into the repository.
  • Export - this is a way of copying the project out of the repository onto your hard drive, without all of the svn tracking directories.
    
    
• Other tools: 
  • If you are using Visual Studio 2003 (soon VS2005), get yourself a copy of AnkhSVN a Visual Studio plugin for SubVersion.  Do NOT use the SCC proxies that are available.  SubVersion does not map well to SCC and you will end up with a lot of the same issues I mentioned above if you try to use SCC with SubVersion, you want to configure this to use _svn instead of .svn, see the next point for an explaination.
  • You will also want to get TortoiseSVN, a Windows shell extension that allows you to manage your projects from file explorer.  Make sure you install the ASP.NET hack if you are using Visual Studio 2003.  If you don't TortoiseSVN will try to use a .svn directory instead of an _svn directory to manage the diff files.  Visual Studio 2003 doesn't support directories that start with a period, Visual Studio 2005 is suppose to fix this issue, but until then we need to use _svn.