A little while ago, I wrote about how I’d started using a version-control system (Subversion) for my source code files. It worked well, but now that I’ve got a really good network-attached storage device (“the NAS” from here on), I wanted to put my repositories on there instead of keeping them on my local drive.

Subversion could easily handle that. The problem is, I use a laptop as my main machine specifically because it’s portable. I’m not always within range of my network, or any network for that matter. And a version control system is used for a lot more than just providing versioned backup copies of your code; I wanted to have a local copy of my repositories as well as the main one on the NAS.

There’s a name for such a creature: a distributed version control system. I’m not going to talk about the details, they’ve been described in lots of other places, in a lot more detail than I’m interested in. I decided on Git, since it seems to be the most popular of the open-source offerings, and offers easy conversion from Subversion (via git-svn).

(Note that although there are GUI programs for Git, they’re primarily viewers rather than full-fledged replacements for command-line operation, like the RapidSVN program I used for Subversion. I’m comfortable enough with the command line, but if you’re not, then Git is not for you.)

Distributed version control is different enough from centralized version control that it took me a few hours of experimentation to get it right. The trick, I found, is to create a “bare” repository on the NAS, and a regular (non-bare) one for your working directory (otherwise you get odd problems when you try to merge them).

To start with non-version-controlled source code, I set up the initial (local) repository by opening a terminal window, changing to the primary directory that contains the code, and issuing these commands:

    git init
    git add .
    git commit

The first one creates the hidden Git directory (containing the repository files); the second tells Git that you want to add all the files and subdirectories in the current directory to the repository; and the third actually puts the added files under version control. If you start a project from scratch, the second and third lines aren’t needed.

Then I created the “bare” repository on the NAS with:

    git clone --bare . /mnt/nas/project-name.git

(/mnt/nas is where to put it — the place that the NAS drive is mounted, in this case — and project-name is the short-name of the project.)

After that, you just need to link the two together. I’m sure there’s a simple shortcut for that (EDIT: there is, see Mattias Reichel’s comment below), but I did it the long way around: I went to the parent of the original directory, renamed the original directory to something else, and issued this command:

    git clone /mnt/nas/project-name.git

Once I made sure that the code was all there, I deleted the just-renamed original directory.

At this point, you can use the local repository the same way you’d use Subversion; the commands are different, but the concepts are similar enough that you can get over that quickly. The QGit program makes it easy to view the different revisions and compare files from them (though it’s different enough from RapidSVN that it took me a while to figure out how to do things in it). When you want to send your local changes to the repository on the NAS (for backup or long-term storage, or to share them with another machine), you just switch to the local directory and call:

    git push

And fetching the latest changes to another clone of the repository (presumably on another machine) should be just as simple, though I haven’t tried it yet:

    git pull

That’s all there is to it. 🙂

Converting the Subversion-controlled projects to Git-controlled ones is fairly simple too, but I won’t go into that here. See this page for details on that. You can even leave your projects under Subversion and use Git locally, though I didn’t try that (Git stores things a lot more compactly, which is more efficient, and I’m all for efficiency).

The end result is that all my projects are now version-controlled with Git, with their primary repositories on the NAS and (for the ones that I’m actively working on) a local repository on my main machine. I have full access to version-control no matter where I’m working, and a RAID-1-protected backup as soon as I return to the office.

I love it when technology works. 🙂