I started reorganizing my home office with an eye toward consolidating and cataloging project code and documentation. I think its normal for most of us to experience growing disorder that often comes with busy schedules. I have lots of little software and writing projects. Some things make it into the correct place while others are scattered about or saved on disks in various states of decrepitude.
From the purely code perspective I’ve used various repositories and version control systems. Several years ago I started with Source Safe while on a long term contract. I was very green with regard to the product but could see the many limitations early on. Later, I used a free version of Vault for my home office but have since adopted SVN. Microsoft has evolved Team Foundation Server (TFS) and the Team Suite of products into its current form but I never had interest from a home office perspective and so far have left that to larger enterprises.
I do nothing very fancy but with my current attempt at consolidating projects I decided to elevate my requirements a little more. So here is what I decided was a short but high value list of these requirements:
1) Remote Access – The SVN server is already constructed this way and for this project I want complete access to my project files anyplace I have internet connectivity.
2) Complete Disaster Recovery – I want every disk drive and computer to fail and still be able to recover relatively quickly. This rules out devices like Microsoft’s Home Server (for this specific application) – if the house burns down I’m sunk using Home Server. Having said that I may be a little unfair here. The main selling point for Home Server is backing up the family computers locally. Of course, an offsite storage capability likely exists but I certainly don’t want to spend the money for a second server then add a subscription fee on top of it. More on the merits of home server in another post.
3) Safe and Reliable Storage – I don’t want to use “Fast Freddie’s” online SVN repository or spend anytime configuring servers.
The other requirements are low cost, full integration with Visual Studio, fast and easy to setup in a short period of time. This sounds like a lot but what many of you already know is that these technologies can be rolled together with almost no effort. Of course I stuck with SVN for my personal use because it meets substantially all of the requirements above except protecting data. For data protection I chose MOZY.
Now, as far as the SVN server goes I needed a build that was easy to install and integrates well with Visual Studio — I chose Visual SVN for both the server and client. The Visual SVN server sets up in minutes.
The following image depicts my current setup
Installing Visual SVN was a “no brainer”. You choose a port and then you’re provided with the URL (https) used to access the SVN server. You also choose the repository location (c:Repository for example).
I then subscribed and installed the MOZY client backup software and configured it to point at the repository folder. Lastly, I configured my home routers port forwarding option which allows access to the server (I also specified windows authentication rather then SVN auth).
The Visual SVN client costs about $50 and the MOZY subscription costs about $5/month. Be careful if you choose Windows 2003 or 2008 because MOZY will detect that and ask you to download the professional edition (which you may want to anyway) but its more money (although still low cost). I also set DHCP reservation on the router but that’s your preference. I’m also installing the Tortoise SVN client on my laptops.
The entire process took about 90 minutes. I will be going through the same process with TFS but expect a higher level of complexity. The main reason for doing this is to explore the options and learn a bit more. For those groups that have moved (or are moving) into TFS from SVN I was recently pointed to a CodePlex project called SVN Bridge which allows use of the Tortoise SVN client (and other SVN clients) against Team Foundation Server.
Also, be sure you check SVN compatibility for the servers and clients you plan on using and keep all files from the original install — this allows for easy re-installation in case of a disaster.
Lastly, remote access as described here would be via IP address, this can be cumbersome. If you’re lucky enough to have a static IP then you probably already have DNS set and a friendly url. If not, your ISP assigns you a dynamic IP with a limited lease life. This means it will change from time to time. One way to avoid the aggravation of attaching back to the SVN server with an IP is to use a service that allows dynamic IP’s to be converted into friendly url’s. The service I use is DynDNS – so my url looks something like myservername.homeip.net.
Be mindful or two things – be sure your not violating your ISP service agreement by hosting SVN. Also, take appropriate network security precautions. Certainly anytime you setup this kind of thing at home your “attack service” increases.
Here are the links one more time:
MOZY – http://mozy.com/
Visual SVN Client – http://www.visualsvn.com/visualsvn/
Visual SVN Server – http://www.visualsvn.com/server/
Tortoise SVN Client – http://tortoisesvn.tigris.org/
DynDNS – http://www.dyndns.com/
SVN Bridge – http://www.codeplex.com/SvnBridge
Microsoft Team Systems – http://msdn.microsoft.com/en-us/teamsystem/dd408378.aspx
Microsoft’s Home Server – http://www.microsoft.com/windows/products/winfamily/windowshomeserver/default.mspx