Git's victory and an entertaining irony

[Eric S. Raymond]

Stephen J. Turnbull <address@hidden>:
> As Eric said, "git has won."  Heck, even Tom Lord (remember Tom Lord?)
> said that git got the basics right, and used the git object database
> as the foundation for his new VCS, revc.

While I am still of this opinion with respect to changeset-oriented
VCSes, something ironically funny happened last week.  I wrote a new
VCS that violates the crap out of most modern assumptions about VCS
design.  And it's a success at version 0.8 - has real users and a
growing dev community.

Yes.  That's right.  I wrote a VCS.  Took me 14 hours to go from 
concept to shippable, documented 0.1.  (Thank you, Python.)

Here's why.  I noticed something about my work habits.  Which is that
even though I judge git has won, it's not the only version-control
system I use.  A significant percentage of my files are maintained in
RCS through VC.  And there's a reason for this that isn't pure inertia.

I have some directories full of single-file projects - FAQs, manuscripts, 
small shellscripts, that sort of thing (my ~/bin is one of them).  I use
RCS on these because I want each file to have a version-control history 
but one that is *separate from the others*.  This exactly violates the 
root assumption of modern VCSes, which designed to manage entire directories
(and subdirectories) with joint histories.

So I asked myself: what would a VCS *specifically designed for this use case
look like*?  There are kluges to address it, with unlovely names like "zit"
(a wrapper around git), but they all throw away at least one desirable 
feature of RCS, which is no binary blobs.  An RCS file is a textfile (unless
you explicitly insert binary data in it).  There are fundamental reasons
this is a Good Thing which I trust I not have to explain on *this* list.

Then I thought: I could wrap RCS in Python, keep the readable history
format, and hide all the ugly crap like RCS version numbers and the
forty kajillion RCS invocation switches.  Then I wrote the manual page.

I called it SRC, "Simple Revision Control", an anagram of RCS.

I wrote the manual page *first*.  I did this because I wanted to think
through the user-interface issues without having my thinking distorted by
implementation issues and the temptation to take wrong shortcuts.

What came out looked like this:

1. Integer revision numbers monotonically increasing a la Subversion.
   This was the single most important decision - they're great if you
   have a centralized file store, and RCS's native revision numbering
   is *nasty*.

2. Lockless operation.  Workfiles are, unlike bare RCS, normally writeable.

3. CLI patterned on Subversion and hg.  "src checkout <file>" does what you
   think it does.  So does "src commit <file>", "src log <file>" and
   "src status".

4. Named tags and branches that work just like you think they should from 
   other systems.  A tag is a named synonym for a numbered revision hat can be
   used in ranges.

5. Two kinds of range literal: M..N follows branch structure, M-N ignores it.

6. Both export and import via fast-import streams. If your project grows
   up enough to become multi-file, you just push a button...

It's deliberately a conservative design with no surprises - the two kinds
of range literal are the closest thing to an innovation in the interface.
My goal was for it to feel ready to the hand of anyone with prior 
experience of the major VCSes.  My alpha users assure me that I have
succeeded in this.

Yes, I will write VC support.

It's already packaged in the Arch user repository.  I have contributions
from three devs besides myself.  About half a dozen users I know of, probably
more I don't.  This is day nine of its life.

SRC: http://www.catb.org/esr/src/

SRC FAQ: http://www.catb.org/esr/src/FAQ.html

And yes. I do think it's funny.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>