Extracting files from an SVN repository backup

Say you’ve got a backup of an old SVN repository. You want to grab a couple of files, but the backup looks like this:

C:myrepo_backup format README.txt conf dab db hooks locks

You figure you probably need to run some fiddly import commands to restore it into a live SVN server so you can connect and browse it right? Wrong! SVN has a feature that makes this incredibly easy: the client can browse and check out directly from a backed up repository on your own local file system.

All you need to do is use the file:// URL scheme and point to your backup, for example:

svn checkout file:///C:/myrepo_backup myrepo

And yes if you’re using Windows, TortoiseSVN does support this — so you can very easily use Repo-browser to explore any SVN backup. Very handy!

Refactoring insight: base project for .NET domain-driven design applications

In the past couple of weeks, I’ve started working on a new framework for my team, for developing domain-driven, test-driven web applications with ASP.NET MVC. Actually, it’s more of a meta-framework: a pattern for application development that leans on as many community-backed, best-of-class tools like NHibernate, NUnit, Rhino.Mocks, Json.NET etc as possible.

From time to time, however, I need to write my own utility class or interface, because it’s too specialised or not available elsewhere. To promote reuse and consistency between applications, I started putting them in a shared Foo.Core project (plus Foo.Core.Tests of course), similar to SharpArch.Core. Unfortunately, it began to turn into a bit of a mess; I had DDD-specific stuff like concept base classes and repository traits mixed in alongside generic LINQ extension methods and other random .NET utility classes.

It’s quite likely that some of the more generic stuff will be used in non-DDD projects, like SharePoint components and addins for Microsoft Office. But to a non-DDD developer, Foo.Core contains a lot of mysterious and scary stuff for whom the purpose of isn’t clear. This is not going to help adoption within my team.

To solve this problem, I decided to split the project in two. I now have a Foo.DomainDrivenDesign project that so far includes:

Repository Traits
Specification bases
DomainException
IEntityValidator<T>, RuleViolation and RuleViolationException
ObjectWithId<T>

The project name makes it immediately obviously what all this stuff is for. The rest has been dumped in Foo.Utilities:

DesignByContract
LINQ extensions

Hopefully in future, the Utilities project can be eliminated completely and replaced by Umbrella or Utilities.NET so we don’t have to maintain it.