Recursion: see Recursion.
Filed under computing, svn
One of my responsibilities at work is to develop and distribute several applications to a different division. These apps all consist of an exe (we’re a Windows shop), some supporting files and an INI config file. They need to be run on several independent PC’s.
The division I am supporting does have technicians, but they are neither hugely technically competent nor blessed with much time to get stuff done, so a “one-touch” installation or update procedure is desired.
There are several ways this could be done, perhaps by distributing an MSI installer which is then installed on each PC. Here is another technique which works for me. It leverages SVN, both because that’s where my code lives and because both sides of this game have access to our SVN server.
- Ensure the exe and additional files are under SVN control.
- Tag the version of the exe which should be distributed. This will be svn://path/to/current/tag
- Create an SVN location with a name something like “current_location“. A good location would perhaps be in the SVN folder of the project, but it really only matters that it is somewhere in your SVN tree.
- Check the “current_location” directory out to a local working copy.
- Create an svn:external property on this working copy, like so:
Check the “current_location” directory back in.
- On each PC the app is to run on, checkout the “current_location” directory. The app will be in a directory called “app” in the checkout location.
The “current_location” directory is now effectively a pointer to the version of the app in current use.
When the app needs updating, create a new tag and edit the svn:external property of your local copy of the “current_location” directory to reflect the new tag and check in. Instruct the technicians to SVN update on their side. This could be done by right-clicking in Windows Explorer via TortoiseSVN for eg.
For a more one-touch solution, I also provide a Windows batch file to automate the checking out of the app on the technicians’ side. This can be quite easily done using the SVN command line implementation made freely available by collabnet (it is of course even easier to do on Unix).
There are some further Windows tricks you can use to make the batch file more comprehensive and useful, but this is enough for now. I’ll write about enhancing the batch file in a (hopefully short-term) future post.
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.