Persisting Content from Virtual Machines (or Why I Am Using Subversion)

One of the problems I always run into when working with several versions of virtual machines is figuring out where the “good” content is. I start up one, do something interesting such as build a neat application, or at least start building one, then shut it down and start working on a new VM. Usually I do this because I discovered a shortcoming of the VM during one of my classes. Then usually during the downtime between classes I sift through all the older VMs looking for interesting content, and then remember something else that was on that VM just days after deleting it entirely. I needed to find a different way of handling this issue.

There are plenty of interesting ways of doing this. One is to create a share on the Host OS that the guest VM can access. Then I can drag and drop the interesting content when I am done. There are plenty of tools to automate this synch making it easier to deal with. But at the same time I had another problem I needed to deal with: version control. I am not a member of a large dev team, but I do spend a bit of time in Visual Studio as well as Microsoft Office apps and wanted a version control system that could handle managing my content. At Captaris we make a document archival/document management tool called Alchemy, but it is not ideally suited to source code control.

Another solution is out there and is written about often. Its freely available, but has a major hurdle going against it. Its Subversion and its hurdle is documentation and ease of use. Documentation is great when you know how to use it, but finding documentation to teach you how to use it is difficult. Everything assumes you already know about source code version control. Its not difficult, but requires you to spend some quality time wrapping your head around it. I spent a good part of the day yesterday doing that and I think I have a solution that will work well for me.

The solution involves Subversion and TortoiseSVN on my host OS, and TortoiseSVN on each of my guest OSes. I am also seeing is VisualSVN makes life easier too. The result is that I can start a project in one VM and spend a little bit of time with setup. Then I can continue the project in my host OS or in any other VM without any extra steps, beyond that initial setup. Its pretty slick. I get the same benefit with Visual Studio projects, Microsoft Word documents, or any other file I create. Looking back at the install process to get this working, it wasn’t very tough. But that lack of good documentation, or more accurately an abundance of conflicting advice, made it a confusing job. And I still have no idea why I created a Branch, Trunk, and Tags directory for no apparent reason….still more reading to do. I’ll write up how I got this far as well as an account of my first experiences with this setup soon.


Submit a Comment

Your email address will not be published. Required fields are marked *