Before I start work for a client I always push to set up some sort of versioning (usually Subversion), regardless of whether there’s going to be a team doing the development or just me. I store the repository on a separate server, just to give the project the best chance at recovery should something untoward happen. (I’ll cover how to do this in a separate post.)

When I’m developing a personal project I do the same. Especially when I’m learning something (and thus I’m even more prone than usual to making mistakes) it’s very handy to be able to tell at a glance what files have been changed or to dump everything and start fresh from the last stable version.

Assuming one already has SVN installed and running on your local environment placing a project under version control is pretty simple.

First, we create a repos for the project. Open the Terminal and type:

svnadmin create /path/to/repos/dir/project_name

You can set up the repos directory wherever you’d like; usually I keep it in /var/svn/ because it mirrors where I’d put it on a live server and I’ve found the closer my dev environment is to the live environment the less confused I get.

It’s worth noting that you don’t need to use complete paths. You could also navigate to /var/svn/ then run this command:

svnadmin create project_name

Because you’re all bright people you’ve already understood that I’m using “project_name” for the name of the project (creative, I know) and that you can name it whatever your little heart desires. I usually prefer something short and memorable because I’m a lazy, slow typer.

Next, we import the existing, non-versioned project into the repos. I usually do this at the point when I’ve invested some real time and effort in the project and I start getting paranoid about messing something up.

As is noted above, do not do this on a project that’s already under version control. Otherwise things get really…weird. Unless you’re keen on Marion Cotillard popping up out of nowhere in winter fatigues trying to shoot you in the face you might look before you leap. By which I mean navigate inside the directory in question and run:

svn info

The proper response is:

svn: '.' is not a working copy

This means it’s safe to proceed with importing the project into the repos:

svn import /path/to/project/directory file:///var/svn/project_name --message="imported project to repos"


Assuming you’ve done everything right SVN will output a list of all files it’s adding to the repos. I have my SVN configured to use VI for logging; the “message” flag writes the note in the project log.

The project has now been commited to the repos. However, the working project is not yet under version control, not really, until we check out a copy. So I archive the current, non-versioned project directory using our friend Tar then (gulp) remove the project directory.

(I’m lying. I never remove it until I’ve completed the checkout successfully and eveything’s cool, and even then usually I just rename it and let it sit around for a while.)

Once you’ve gotten through your tiny flash of professional angst over whether to delete or not, it’s time to check the project out of the repos:

svn checkout file:///path/to/project/repos /path/to/project/directory/project_name

You don’t even need to create a target directory (in this case named “project_name”) as SVN, ever accommodating, will do it for you.

That’s it. Usually I need to exclude a few directories from the repos before I get started again.