Category Archives: svn

As part of this Programming Subreddit discussion on why Visual SourceSafe (VSS) gets such a bad rap, I suggested to a commenter who had stated that they didn’t see anything wrong with VSS that they should try SVN on the side, as a lot of the benefits are only apparent through experience, not through being told about them. I was asked for reasons why SVN is better, and I wrote enough text that I’m going to reproduce (and slightly expand) it here, so I can find it again if I need it:

• Branching: SVN makes branching quick, easy, painless and cheap (in the sense of disk space). In our experience, we did very little branching, and carefully considered the need for a branch before doing so when using VSS, as it took so long to do and was a fiddly process. Under SVN, we branch whenever needed, which has enabled us to use a smoother workflow: bugs and new features can be fixed in their own branch and easily brought back into the main code when they’re ready. Previously we would have had to keep local copies only of whatever we were working on for a few days until it could be brought back into the code without breaking what other people were working on, since branches were such a pain to work with and create.
• Speed: SVN makes getting the history of a file, directory or entire project much quicker than VSS was able to do it. This makes it easy to look at previous versions, compare them to each other and even compare them to files in different areas of the same repository (which I recall VSS making quite difficult, if not impossible without getting all the files locally first).
• Backups: An SVN repository is a flat file system on your servers filesystem, which can be backed up easily. Tools are also available to back up a repo which is in active use, so no disruptions are made to development efforts while backing up or administering the source control system.
• Maintenance: SVN repos do not require offline maintenance or analysis – no need to have the system unavailable for long periods of time while doing maintenance.
• Remote access: SVN can be accessed over a network via HTTP (using Apache, generally) as easily as it can be accessed remotely. VSS, if I recall, cannot do this, and needs a separate product like Source Offsite to support this.
• Command line tools: SVN has a comprehensive set of command line tools (in fact, SVN is a command line tool at heart). This makes it easy to automate – checking out builds automatically for building and testing for example. This is probably one of those areas where one can’t imagine what possible use it would be until it’s available (based on my own experience).
• Explorer integration: The (freely available) TortoiseSVN product provides a GUI with all the functionality of VSS, which also integrates into your Windows Explorer – so you can see at a glance which files are up-to-date, which have changed etc.
• Tool integration: Many IDE’s and text editors can be integrated with SVN, and the SVN hooks are available to write such integration if it doesn’t exist for your tool. This is possibly another area which doesn’t seem useful until you’ve tried it.
• Hooks: SVN provides a variety of hooks to enable actions to be taken before or after committing or checking out code. This allows for running checks against checked in code to ensure it meets some requirements, or emailing interested parties when code is checked in. With VSS we did all of that kind of thing manually, which was error prone.

I suggested SVN not because I consider it the best possible VCS, but because it’s more like a “VSS that actually works” than a DVCS, and because I have some experience in the migration from VSS to SVN.