[web-team] Quick summary of new web host

[Rick Moen]

Quoting Mark Weisler (mark at weisler-saratoga-ca.us):

> As someone who will likely be using the version control system in the future, 
> I do hope Rick, Lisa, and whoever else have input make a good decision.
> I don't know enough about this to have an opinion as to which one is best for 
> our situation.  I agree with Rick, now is the time to pause, think a bit, and 
> make a good decision because once we start using a system will will be 
> difficult to change.

Some points:  

1.  Mark, I recommend reading this short draft analysis paper by Eric
Raymond, to understand the big-picture nature and context of version
control system (VCS) software, along with where rcs, cvs, and svn
(Subversion) and several lesser-known _decentralised_ alternatives fit
in:  http://www.catb.org/~esr/writings/version-control/  There were some
really key concepts I didn't "get" until I read Eric's draft and started
helping him improve it.

Reading that short paper will give you some "Aha!" insights into VCSes
you may have used or read about.  It won't really help you use or
administer any, but I recommend it for other, overall-knowledge reasons.


2.  My comment that svn is "heavyweight, with a large number of
dependencies" seems to be somewhat outdated:  I notice the dependencies
list has been shrunk quite a bit, since a few years ago when I last
looked closely:

   $ apt-cache show subversion | grep Depends
   Depends: libsvn1 (= 1.4.4dfsg1-1ubuntu3), libapr1, libc6 (>= 2.6-1), libsvn1 (>= 1.4)

It used to drag in a whole lot of Apache2-related software, mostly for
the WebDAV support, plus other things.  That seems to have been fixed.
It's still a bit large and slow, thus the "heavyweight" bit.

Mercurial needs basically just python:

   $ apt-cache show mercurial | grep Depends
   Depends: libc6 (>= 2.6), python2.5, python (<< 2.6), python-support (>= 0.3.4), python (>= 2.4)

Ditto Bazaar (bzr):  

   $ apt-cache show bzr | grep Depends
   Depends: libc6 (>= 2.6-1), python-central (>= 0.5.8), python (<< 2.6), python (>= 2.4), python (>> 2.5) | python-celementtree

"git", being in C and extremely lightweight/small/fast, requires nothing
that isn't on basically any *ix system already:

  $ apt-cache show git | grep Depends
  Depends: libc6 (>= 2.5-5), libncurses5 (>= 5.4-5), libreadline5 (>= 5.2)



3.  It turns out that VCSes in general inevitably get tailored to the
use cases of developers, and thus (in general) only poorly fit the needs
of sysadmins.  For example, in general developers don't give a damn
about file ownership, permissions, and symlinks (and other special
files) -- which tend to be crucial for sysadmins, e.g., under /etc.  In
consequence, only lately have some VCSes aspired to track accurately
changes in such things.  (Some/most VCSes never have and never will.)

For the same reason, documentation tends to be opaque and
developer-centric, especially concerning use scenarios other than those
of typical coders.

For lots of reasons, "git" came rapidly out of nowhere in April 2005 and has 
gotten huge mindshare with coders.  Here are some tutorials recommended by Don
Marti:  http://zgp.org/pipermail/linux-elitists/2008-April/012451.html
I've also found: http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html
Good tutorials have been badly needed, because git occupied something of
an information void for the first couple of years (except among the
kernel gang).  It was also a rapidly moving target, and much of the
early writings about it are partially obsolete, e.g., my own VCS
survey's (http://linuxmafia.com/faq/Apps/vcs.html) mention of the
"git/Cogito" combination (see: http://git.or.cz/cogito/) is obsolete
because Cogito was in 2006 _replaced_ with git's own rapidly improving
user interface.


4.  Here's an example of how VCSes have been slanted towards coder use
and away from sysadmins' needs:  Systematically tracking /etc changes
has been one of the most-wanted features sought by sysadmins in such
software for a long time, but all that ever emerged by several years
ago, was a feeble and awkward tool called 'IsiSetup".  Finally, last
year, Debian developer Joey Hess invented something much, much better
called "etckeeper".  It uses git for back-end storage (later,
more-awkward and less-well-documented optional support for Mercurial and
Bazaar got added), but git wasn't quite good enough by itself to
accomplish the full job:  It doesn't capture (some of...) file
permissions, ownership, mtimes, etc.  So, Joey had to hack into it a
second existing tool called "metastore", which grabs that data at
etckeeper checkin time and stores that metadata in git, encoded in some
fashion that git can handle.

When installed onto Debian or *buntu, etckeeper _automatically_ captures
any /etc changes resulting from (any, all) package operations.  That's a
big gain, right there.  Any strictly manual edits / adds / deletions to
/etc contents still need to be checked in manually, but the hooks to
metastore mean you at least capture _everything_ you care about,
including file ownerships / permissions / mtime, etc.

We can trivially add etckeeper to the Linode setup.  However, it cannot
use svn for etckeeper's back-end storage.  Any difficulty setting up
version-tracking for /etc -- even bad, feeble version tracking -- gets
richly rewarded the first time you notice that your DNS nameserver isn't 
willing to load one of your zonefiles, and you have no idea what you
changed in the zonefile that might have caused the problem.


5.  What I'm driving at is that momentum and the logic of what is coming
into existence seems to favour our just using git, generally -- and
specifically etckeeper back-ended into git for tracking of /etc.  The
bad news is that blasted learning curve.  (I have only the smallest
amount of experience with it.)

However, any VCS at all is a huge, staggering improvement on none.  (I
mention this fact because sometimes in system administration seeking
what is best delays you from implementing something that is better than
nothing, and that's often a serious strategic error.)