James Skemp's StrivingLife

A new feature in Windows 7 and Windows Server 2008 R2 is the ability to work with Virtual Hard Disks (VHDs) directly within the OS, by booting from them or mounting them as additional drives.

While I've had a good deal of experience with using VHDs in virtual environments, being able to work with VHDs directly is fairly new, and leaves some question as to how useful it could potentially be, since I'm happy using VirtualBox to work with virtual machines when I need to do any testing.

Creating a VHD

It's extremely easy to create a new virtual hard disk.

Open the start menu and type "disk," then find "Create and format hard disk partitions" to open Disk Management. Under Action select Create VHD. Browse to or enter a location where to store the disk, what size to create, and select the format of disk to use (fixed size being universally recommended, from what I can).

An unallocated disk will be added to the bottom half of the Disk Management window, and will be noted as 'not initialized.' Right click on the left-side - not on the display of the disk - and select "Initialize Disk" from the menu.

Take note of the note, and either change the partitation style (seemingly more applicable for larger disks) and press OK.

Next right-click on the display of the disk and select "New Simple Volume..." from the menu. A wizard will start which will walk you through the process of specifying a volume size, assigning a drive letter, and formatting the volume.

After a format the disk will be attached and AutoPlay should trigger.

Working with the VHD

Now that you have a VHD created and attached you can add new files to the drive, as you would with any other. Once you're finished with the disk you can detach the VHD back in Disk Management. (You also have the ability to delete it after removing it, if you so desire.)

If you need to add it back on later you can select Action > Attach VHD to browse to the location of the virtual hard disk, and can even make it read only if needed.

Working with VHDs in VirtualBox

Unfortunately it doesn't appear that detached VHDs can be used in Sun's VirtualBox as additional drives.

Encryption and security considerations

Short of a higher-end version of Windows 7, or a third-party application, it doesn't appear that any level of encryption is available on created VHDs, which limits their use as storing secured documents. However, excluding times when the VHD is attached, Windows (7) doesn't appear to search within them, which means they may still serve against non-technical users.

Portability

The fact that they can't be attached directly via VirtualBox is unfortunate, but doesn't mean that the VHDs couldn't serve to consolidate information into a single file, which could then be copied from computer to computer, as needed. While we lose out on compression, in the case of using some sort of compressed file format, we seemingly get faster access to the content.

Definitely further testing is required.

Additional information

Microsoft has a Virtual Hard Disk Getting Started Guide, but it focuses more on the administrative benefits of using VHDs for building new PCs, or testing, as opposed to using them as virtual drives.

For a business to implement version control, they typically want some kind of support, preferrably that they need to pay for, and that may or may not be used, and that may or may not be helpful.

Luckily, CollabNet offers certified binaries of Subversion, available for the low price of the time needed to register. Additionally, they offer support, training, installation, and hosted solutions, in addition to the large Subversion community. Compared to the other solutions out there, including Microsoft's, there's really no question on what your first choice should be.

In this article I'll be going over the base installation of CollabNet Subversion Server 1.6.3 and TortoiseSVN 1.6.3.16613, on Windows Server 2003 R2 Enterprise Edition, Service Pack 2, running on Sun VirtualBox. Screenshots are available by clicking on the appropriate links. (Due to the size, they are not included here, but I might do some jQuery to have them display nicely, at some point.)

Downloading installers

The first step is to download the installers for CollabNet Subversion Server and TortoiseSVN. At this time, the current versions of each are 1.6.3.

Installing CollabNet Subversion Server

CollabNet Subversion Server relies upon Apache to serve repositories, due to the various benefits (security and etcetera) that it provides. However, for this installation I'll assume that you want to keep IIS running and available.

Start the installer and read and click Next on the first and second screens. On the third screen you'll be able to choose whether you want svnserve to run as a Windows service, as well as Apache. For these, you want to keep the default of having both checked.

Assuming you've done that correctly, on the fourth screen you'll be able to choose what port Subversion should use (default is 3690) and the directory to store repositories (default is c:\svn_repository).

On the next screen you'll setup Apache. If you wish to continue running IIS on port 80, you'll need to use a different port (80 changed to 8080 in my case) and/or change the host to a name that IIS is not using. You'll also set where the repositories are being stored (from the previous screen) and what path to use when navigating via HTTP.

You can also enable viewVC, but Active Python 2.5 must be installed. By default viewVC is not enabled (and I don't go through that installation here).

Finally, you'll choose the location to install CollabNet Subversion Server on screen six, and be presented with the Finished screen once the installation is complete, which includes links to CollabNet products and services.

A restart will be required in order to start the necessary services. Once the restart is complete you can verify that you can access Apache through the browser, as well as run the svnadmin --version command to verify that Subversion is installed. See this.

Installing TortoiseSVN

The next step is to install TortoiseSVN. I've covered TortoiseSVN a number of times on this site, and installing this version isn't much different.

Accepting the defaults will get you through the install process (captures: 1, 2, 3, 4, 5, 6), and you'll need to restart once the installation is complete.

Testing repository creation and usage

At this point, you should be set to begin working with Subversion.

Create a new directory in your repository directory (default is C:\svn_repository). Then right-click on the directory and select TortoiseSVN > Create repository here.

The repository will be created, and you can verify by opening the directory as well as navigating to it via HTTP.

We can now checkout a copy by right-clicking anywhere and selecting SVN Checkout ....

Enter the URL of the repository and a checkout directory to continue. See this.

You should then be able to browse to that path and see that you have a current directory. You can then create a test file and commit your changes to verify things are working correctly.

You can make another change, verify that things commit, and then browse, via HTTP or the repository browser, to ensure that you're at the appropriate number of commits.

Next steps

And with that, you've successfully installed CollabNet Subversion Server 1.6.3 and TortoiseSVN 1.6.3. Now you just need to use Subversion during development.

CollabNet also offers free tools for Eclipse and Visual Studio, to help you integrate with your favorite IDE.

You can also play around with the security options that are available due to Apache, to make Subversion as secure as you need it.

Having just upgraded to VirtualBox 3.0.0, I was running into an issue with being able to access a Windows Server 2003 guest from my Windows Vista host machine.

By default, when creating a Windows Server 2003 guest machine the Network settings are set such that Adapter 1 is PCnet-FAST III, attached to NAT. This allows the virtual machine to get outside, but not in.

However, it's possible to add a second adapter, attached to the host-only adapter. In this way you can access the outside world, as well as allow your host machine to access the guest via it's host-only ip (192.168.56.x, for example).

Unfortunately, there seems to be no way to set this on all future machines you create.

Windows Server 2008

The same, with a different adapter (use the default), is possible on Windows Server 2008, as well. If you're testing via ping-only (you've just set it up, for example) then you can temporarily disable the firewall for the specific adapter you setup as using the host-only adapter. Pinging the ip (from ipconfig) should then work, and provide the correct ip.

Windows 7 RC

As with Windows Server 2008, you'll need to turn off the firewall to allow pings by ip or computer name. Unfortunately, unlike Windows Server 2008, individual adapters do not seem to be listed in 7, so you'll either need to play with it, or just turn off the firewall for each network listed.

For future use ...

In the VirtualBox documentation, they have a pretty nice example of a network setup.

In this example there is a Web server and a database server. Both are setup as a host-only network. The Web server has an additional, bridged, network. This nicely cuts off the database server from the outside world.

Along these same lines, instead of using NAT for the first adapter, and having to create a second adapter, we could always just change to a bridged network. However, for my development needs, I don't see a reason to do so.