Switching to Subversion

["Jim Blandy" <jimb@red-bean.com>]

I designed the Subversion repository structure, and began the work on
the first filesystem implementation, so I can answer some of the "what
were they thinking?" questions that have come up on this thread.

We were aware from the beginning of the importance of merging.  We had
long discussions on what merging should mean, and the fellow who
handles version control for HP's inkjet printer division (they use a
big changeset engine) came to talk to us about changesets.  We all
agreed that changeset-based systems with interfaces like Darcs and
BitKeeper were The Right Thing, and the most useful way to think about
the whole activity of collaborative development.

However, we didn't implement that because we couldn't see any way to
do it in a way that scales to very old repositories.  For example, the
GCC repository has 118807 revisions in it at the moment, and handles
them just fine.  I don't see how a system with a repository structure
like Darcs (which I use and absolutely love) is going to handle that,
unless you're willing to rearrange your repository to trade speed for
historic detail.  And there have been comments from Larry McVoy to the
effect of, "big deal, everyone falls down with a few tens of thousands
of revisions".  Subversion has demonstrated that that's not so.

>From discussions with other people who follow these things more
closely, I understand that Mercurial has an excellent repository
structure: very compact, very fast, and very versatile.  The
Subversion project has plans --- which should be weighed as just that,
plans and talk --- to incorporate some of Mercurial's characteristics
in its merge support.

I do occasionally see a tendency in programming circles for people who
have recognized others' good ideas to adopt the strut earned by the
person who actually had them.  It always looks a little strange.