Something you only hear once a project....

... and let me tell you, it's an unbelievably sweet sound:

Test Manager: "Let's branch the code base, place a code freeze on it, and burn an install DVD labeled 'Release Candidate 1'".

After 15 months, I really can't think of a nicer thing to hear at this point. It's a concrete sign that the hours upon hours of overtime, the heartache of making the multitude of mistakes that are always made on a project, the (at times seemingly endless) stream of bugs from QA is all finally coming to an end.

More importantly, it's the sign that the client is finally going to get the application they've been promised for almost 5 years, a sign that for thousands of end users the dawn after a long night of *shudder* legacy is finally brightening the horizon.

For those that get here having been involved in the project, I cannot even begin to conceive how I could thank you enough for what you've done to get it to this point. You are more than aware of what has gone into this DVD, and even though some of you bailed early (no sinking ship metaphors please), I wouldn't have been able to write this without you.

15 months.
17 Developers.
1.8 million LOC.
Fixed Price.
On Time.
On Schedule.

Thank You.

Syncing SVN Repo's, Step by Step.

As mentioned in a previous post, I've been playing with Trac etc lately, so I've been doing some more advanced SVN work while I'm there. It's my Source Control system of choice, so I should probably learn how to use it correctly!

For posterity, here's how I've configured a sync of one SVN repo to another.... you might do this for testing an existing repo against a new tool on another machine (like my Trac VM efforts the other day), or as a warm-standby in the event of server failure etc.

Some assumptions: I'm not using Apache to run the local server, I've always used the path of least resisitance and just used svnserve.exe... either directly via the -d (daemon) flag, or as a windows service.

We're going to sync the remote (source) repo (which lives at svn://192.168.1.1) with a local (target) repo, using the built in svnsync tool. This tool doesn't like any other user changing the target repo once it's initialised, so we're only going to allow a single user access to the target.

1. Create the new local, target repository. svnsync requires a totally blank repo to start with... this means if you use Buildix and you've created a new project, you're out of luck because it initialises the repo to revision 1, due to the default folder structure. You'll need to blat the repo off disk and create it again.

svnadmin create D:\SVN_REPO

2. Configure the users/permissions on the target repo:
2.1 Change conf\svnserve.conf to include the following:

anon-access = read
auth-access = write
password-db = passwd

You can alter this as you need to, but these are the defaults... for some reason unless I uncommented these lines, my svn didn't want to honour the defaults... YMMV.

2.2 Add a user to the local repo for the sync process to run as. svnsync actually pumps the data into your repo using the normal svn API, so it needs a user to connect as. Alter passwd to include a new user:

svnsyncuser = svnsyncpassword

3. Configure the repository hooks. svnsync requires a pre-revprop-change hook to be in place, here's the simplest version:
3. 1 go to hooks
3.2 Create a couple of new files called pre-revprop-change.bat and pre-commit.bat
3.3 Alter the contents to be "return 0" <- that's a number zero
3.4 This tells the hooks to do nothing, but return success (code 0)

There's nothing to stop you doing more advanced hooks to ensure it's only the allowed user making repo changes etc if you want, but I'm K'ingISS.

4. Create a new user in the remote/source repo, using the same username/password as our freshly created user from Step 2 above.

This may not be needed, but it saves security issues around using one account to connect remotely, and another to connect locally. I have access to the remote repo, so I'm going to use it :)

5. It's time to initialise the sync!!
5.1 Stop any locally running SVN server process (apache or svnserve)... this is important
5.2 run the following command:
D:\>svnsync init file:///SVN_Repo svn://192.168.1.1/ --username svnsyncuser --password svnsyncpassword

Note that we used the file:// protocol to point to the repo, which exists at /SVN_Repo from where we ran the command (D:\). We also pass in the remote repo, and the user/pw to connect as.

If this goes smoothly, you should see "Copied properties for revision 0.".

6. At this point we can start up the local SVN Server (daemon mode, rooted at our repo):
start svnserve -d -r d:\SVN_REPO

7. Time to make initial sync, this is where all the hard work pays off!
svnsync sync svn://localhost --username svnsyncuser --password svnsyncpassword

This may take a while, as it propagates each revision from the source to the target one at a time.

To keep the repo in sync, you can either run the svnsync sync command in a bat script (using at, Scheduled Tasks etc), or configure a post-commit hook on the source repo as described at this really handy tutorial.

Remember you're dealing with Source Control, the single most important element of a software project... take backups before you start, and think before running any command that alters data to ensure you're running it on the right server etc.

Enjoy :)

Hyper-V Errors

I've been using Hyper-V for my virtualisation requirements lately, and in general it's been very smooth. I'd love the memory-sharing of ESX given I'm running a dev/test box, not a prod server, but so be it.

I just went to kick up a new VM, attached the DVD Drive, and promptly had the following spat at me:

'MachineName' failed to start. Microsoft Emulated IDE Controller (nasty guid) : Failed to power on with Error 'The process cannot access the file because it is being used by another process'.
Failed to open attachment 'E:'.


Ouch.

Nothing else on the host server was using the DVD drive, but one of the other VM's still had the physical drive assigned to it. Disconnecting it allowed the new VM to start straight away.

Attempting to re-attach the drive to the existing VM then threw a very similar error.

Moral of the story: Apparently only one(1) VM can have access to the physical CD/DVD drive at a time.

Hope this is sufficiently detailed to help out the next poor sap that runs into this.

All the small things....

... seem to drive you mad.

Note to self: svnserve.conf does NOT like having leading spaces on it's lines.

In my defence, I've spent the last 5 hours trying to get an svnsync from my main SVN repo (running on my NAS) into my new Buildix VM working so I can have a play with things like Trac without having to 'invent' commits/issues etc.