How'd this get started?: "Lots of things.
First, when I was a working student, years and years ago, some of the
people I respected and was trying to learn from were interested in a
topic they called "programming in the large": the question of how to
manage programming projects involving hundreds or thousands of
programmers. I became interested in that problem and revision control
is a subset of that problem.
Just a few years ago I had a stint consulting for a (now defunct)
research lab at a major telecom company (I wrote them a version of
malloc with debugging features and made some modifications to GCC to
make those features more useful). My boss there had asked me to use
CVS to "make [him] less nervous." I couldn't. CVS just makes my skin
crawl. Most of the time it just gets in the way and the critical core
things its supposed to help with, like branching, merging, and
tagging, are just painful and awkward with CVS. It's a horrible
system. At that time, I did spend a few weeks on a skunk-works
project to invent something better -- you know, to make my boss less
nervous by at least using _some_ form of revision control. That
little project failed and failed hard. I didn't understand, back
then, the importance of branching and merging --- I just wanted
something to snapshot my source trees. I got that, but even as just a
limited system it was way too slow and used up way too much disk space
(even by my standards as a notorious disk-hog).
It was around (slightly before) that time that I noticed the
Subversion project. I found it particularly interesting for two
reasons: (a) they were promising smart merging features; (b) they
decided to make the storage management part of Subversion a
transactional filesystem. I'm a big fan of the general idea of a
transactional filesystem so Subversion sounded like a great project.
I later came to regard Subversion as a very flawed design and
implementation but it wasn't really a question for me back then ---
this was sufficiently early in the lifetime of Subversion that I
couldn't really use it anyway. (As I recall, this might even have
been back before Subversion was a "self-hosted" project -- before the
development team itself was willing to rely on it. A long time ago.)
Some years later I was unexpectedly unemployed (a long painful story,
there). This was after the .com bubble had burst so tech jobs were
pretty hard to come by where I was living (the San Francisco Bay Area;
Silicon Valley; the epicenter of the economic earthquake).
Out of desperation as much as anything I thrashed around trying to
find a free software project I could do quickly in order to try to
salvage some semblance of a career; to have something I could put
on my resume and say "hey, see what I can do?" Maybe, if I got very
lucky, to have a project I could make money from directly.
During that search I "renoticed" Subversion and revisited the whole
issue of revision control systems. I thought about the issues more
than I had in the past: what the requirements for storage management
are to avoid using too much disk; what's needed from branching and
merging; how to do atomic commits of whole trees --- that sort of
thing.
With all due respect to the Subversion folks, many of whom appear from
over here to be very good hackers, I realized that they had completely
blown it. Subversion is a dog. It's a horrible, horrible design
based on a few very good ideas. It's hard, I think, for casual
observers to recognize the problems with Subversion given the good
ideas it contains, the high skill level of the developers, and the
good job of project management they do --- but the problems were
enough to prevent me from just joining the Subversion project.
I realize that that's more than a little bit inflammatory so please let
me qualify it a bit. I'm well aware that many people now use
Subversion and are reasonably happy with it. In my view it's _not_ an
improvement over CVS because it takes too many steps backward in
various areas --- but at the same time I recognize that in spite of
those backwards steps, it also gets a few things right that CVS does
not. If those are the only things you are really paying close
attention to, Subversion is from your perspective an improvement over
CVS.
But for me, it was clear I wouldn't want the hassle of maintaining a
Subversion archive in my environment: the admin burdens are too large,
worse than CVS it seemed to me. And it was clear I wouldn't want to
hack on Subversion itself: the code was way too large and complex for
what seemed to me had to be a much easier problem to solve. I'd very,
very much wanted the smart merging features that they've long promised
but not yet delivered.
In short, part of what propelled me to write arch is just simple, old
fashioned, ego-driven rivalry: I wanted to show those folks up."
