platypope.org

I've been meaning to do this for quite a while, but I finally have my entire home directory under revision control. I've been keeping most of my important rcfiles in a Subversion repo — and of course no source code goes unversioned — but everything else has just never made it into anything other than my... um... "infrequent"1 off-site back-ups. Until now!

I looked briefly over several version control systems before finally deciding to stick with Subversion. It's stable, the most widely used by open source projects (after CVS), hacked on by someone I know, and only lacks one feature I'd miss. Work-use of SCM might have affected my decision, but my current day job is using StarTeam2 so... no.

The one feature I'd miss is distributed development. All the cool kids are doing it — not to mention the more recent change-set oriented OSS version control systems. So I'm layering that on with SVK. If you haven't heard of it, SVK is... well... a giant hack. And written in Perl none the less. It essentially uses the Subversion libraries to implement an alternate interface for working with Subversion repositories. The main intent is something like distributed development3, but the way SVK goes about it has some interesting effects.

The big one is how working copies are maintained. The SVN tools maintain with each working copy a pristine copy of the revision checked out from the remote repository. This allows for fast revert, diff, etc., and is also probably the easiest way to allow preparation of the change-set for commit. SVK instead of maintaining that pristine revision, mirrors the remote repository. This allows diffing not only against the checked out revision, but against any revision in the mirror — or between any revisions in the mirror. Want to checkpoint some experimental code? Commit it locally and only push it out after it's finished. Need to switch from your experimental code to mainline development? Create local branches switch your working copy between them at will.

And this is kind of petty, but not having those .svn directories in each checkout means I can stop using this monstrosity:

export SFIND_PRUNE_PATS='*~:*/CVS:*/.svn'
sfind() {
    local dirs=''
    while [ $# != 0 ]; do
        echo "$1" | grep '^-' >/dev/null 2>&1 && break
        dirs="$dirs '$1'"; shift
    done
    local opts="$(squote "$@")"

    local prune_args="-path '$(\
        echo "$SFIND_PRUNE_PATS" | sed -e "s,:,' -o -path ',g")'"
    eval "find $dirs \
              '(' '(' $prune_args ')' -prune ')' \
              -o $opts -print"
}

SVK used to have a reputation for being a bit unstable. So far, the only problem I've had there is trying to use version 2.0's "views" feature, which is clearly tagged as "very beta." And even if it does fall over, my "real" repository is still just plain old Subversion.

Lest I mislead you into believing SVK to be all kittens and sunshine, I have had some problems. SVK doesn't allow overlapping working copies, so keeping all of ~ in a repo involves symlinks. SVK keeps all pending non-file changes4 in one big YAML file — prepare a commit with a lot of deletes, and you can feel the parse time. SVK doesn't support svn:externals, so WYSIWYG when it comes to your repo's directory hierarchy. SVK's "views" are supposed to provide similar functionality, but in addition to not being there yet implementation-wise, they seem a bit off design-wise — and still aren't svn:externals. And did I mention that it's written in Perl?

But it's mostly kittens and sunshine, and I don't have to worry about letting cups of coffee near my laptop anymore. For next blog post: where I'm keeping this homedir Subversion repo of mine...

1 i.e., usually made shortly after some sort of laptop + liquid incident.

2 I can vaguely understand using a proprietary version control system, but one which didn't have atomic commits until its most recent release? Come on, people.

3 Projects are still tied to a central repository, which is either impure or just practical, depending on how you look at it.

4 Directory hierarchy changes, property modifications, etc.