

If Version Control Systems were Airlines - wallflower
http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines

======
telemachos
The link in this to the famous (?) "Operating systems as airlines" joke has a
different version from the one I'm most familiar with.

Here's an alternative: <http://tldp.org/LDP/LG/issue45/orr.html>

(The punchline to the Linux airline is priceless, I think.)

Edit: If you like this sort of humor, Neal Stephenson's "In the Beginning was
the Command Line" has a great extended analogy where operating systems are car
dealerships. A link and a snippet:

 _Imagine a crossroads where four competing auto dealerships are situated. One
of them (Microsoft) is much, much bigger than the others. It started out years
ago selling three-speed bicycles (MS-DOS); these were not perfect, but they
worked, and when they broke you could easily fix them.

There was a competing bicycle dealership next door (Apple) that one day began
selling motorized vehicles--expensive but attractively styled cars with their
innards hermetically sealed, so that how they worked was something of a
mystery.

The big dealership responded by rushing a moped upgrade kit (the original
Windows) onto the market. This was a Rube Goldberg contraption that, when
bolted onto a three-speed bicycle, enabled it to keep up, just barely, with
Apple-cars. The users had to wear goggles and were always picking bugs out of
their teeth while Apple owners sped along in hermetically sealed comfort,
sneering out the windows. But the Micro-mopeds were cheap, and easy to fix
compared with the Apple-cars, and their market share waxed.

Eventually the big dealership came out with a full-fledged car: a colossal
station wagon (Windows 95). It had all the aesthetic appeal of a Soviet worker
housing block, it leaked oil and blew gaskets, and it was an enormous success.
A little later, they also came out with a hulking off-road vehicle intended
for industrial users (Windows NT) which was no more beautiful than the station
wagon, and only a little more reliable.

Since then there has been a lot of noise and shouting, but little has changed.
The smaller dealership continues to sell sleek Euro-styled sedans and to spend
a lot of money on advertising campaigns. They have had GOING OUT OF BUSINESS!
signs taped up in their windows for so long that they have gotten all yellow
and curly. The big one keeps making bigger and bigger station wagons and ORVs.

On the other side of the road are two competitors that have come along more
recently.

One of them (Be, Inc.) is selling fully operational Batmobiles (the BeOS).
They are more beautiful and stylish even than the Euro-sedans, better
designed, more technologically advanced, and at least as reliable as anything
else on the market--and yet cheaper than the others.

With one exception, that is: Linux, which is right next door, and which is not
a business at all. It's a bunch of RVs, yurts, tepees, and geodesic domes set
up in a field and organized by consensus. The people who live there are making
tanks. These are not old-fashioned, cast-iron Soviet tanks; these are more
like the M1 tanks of the U.S. Army, made of space-age materials and jammed
with sophisticated technology from one end to the other. But they are better
than Army tanks. They've been modified in such a way that they never, ever
break down, are light and maneuverable enough to use on ordinary streets, and
use no more fuel than a subcompact car. These tanks are being cranked out, on
the spot, at a terrific pace, and a vast number of them are lined up along the
edge of the road with keys in the ignition. Anyone who wants can simply climb
into one and drive it away for free._

<http://www.cryptonomicon.com/beginning.html>

~~~
Groxx
_Anyone who wants can simply climb into one and drive it away for free._

After they RTFM for how to start it. Attempting to drive away without that may
result in seemingly random explosions.

That, and the consensus for anyone not in the consensus is that they should go
fork themselves. The forked ones frequently agree.

------
pilif
it's time to drop the prejudice against git's UI. The time where git was
incredibly hard to use and required total knowledge of its inner workings are
long past.

In it's most basic pattern of use, it's not more complicated than subversion,
but of course, then you are not using the majority of the features that make
git so nice to work with and that help improve the quality of your code base.

But even if you are using this additional features (rebase -i, add -p,
bisect), it's not hard to use and for sure it's never acting in unexpected
ways.

Sometimes, the opinion about git feels like all the people saying that
PostgreSQL is hard to use and slow. Can't people get over paradigms of the
past?

I lived and worked in days when git was hard and PostgreSQL slow. Didn't stop
_me_ to see the change happen and to begin using them. Why can't others see
and don't stop retelling the same old and obsolete stories over and over, be
it in an earnest of funny (like this one here) package.

(disclaimer: I'm in a really bad mood today and I don't know why. I don't want
to troll. I'm just bitter)

~~~
stevelosh
I think git's UI is terrible for one main reason: each git (porcelain) command
can do a whole bunch of unrelated things.

Want to switch to a different branch (or tag/revision hash)? 'git checkout'

Want to change a single file's contents to a previous version? 'git checkout'

Want to create a new branch? 'git checkout'

This becomes a problem because 'git checkout' has to have many different
options to be able to do all of these things and all of these options can
interact in different ways.

This makes the 'git help' for every command enormous because it needs to
document the interaction between all the different options. Large help docs
are hard to read when you're in the middle of working and just want to know
how to do something specific.

Contrast git's help with Mercurial's equivalent helps:

    
    
        $ git help checkout | wc -l 
            236
    
        $ (hg help update ; hg help branch ; hg help revert) | wc -l
            100
    

Mercurial's docs are less than half the length of git's. This isn't because
Mercurial isn't well documented -- it's because Mercurial splits up
functionality into small, independent commands that do one main thing each.
Mercurial's help doesn't need to waste time saying stuff like "if you use
--foo then --bar means X, but if you use --bar on its own it means Y, and
neither of them can be used with --baz".

 _This_ is why I hate git's UI. There's so much functionality crammed into
every command that the docs for each command become impossible to scan (try
'git help log | wc -l' for laughs).

~~~
chousuke
If you think of "git checkout" as "update the working copy", doing all those
things with a single command makes a lot of sense.

The "create a new branch" functionality doesn't really belong in your list,
since branches are created with "git branch". The -b switch is provided for
checkout because _updating the working copy_ and creating a new branch is a
very common sequence.

To be honest, I have yet to find anything I particularly dislike about git's
approach. For some things, it took a while to see why it is the way it is, but
in the end I find it fairly sensible. In my opinion, git just does things
right on a fundamental level[1], which I find more important than UI issues.

[1] Compared to hg, especially the 'a branch is just a pointer' approach. I
know of the bookmarks extension for hg but in the end I just used hg-to-git
for the one hg repository that I follow.

~~~
stevelosh
> If you think of "git checkout" as "update the working copy", doing all those
> things with a single command makes a lot of sense.

The problem is that "update the working copy" isn't accurate.

When you 'git checkout my-feature-branch' you "update the working copy" AND
"switch the current branch to my-feature-branch".

When you 'git checkout fa230bc -b new-branch' you "update the working copy"
AND "create a new branch".

> The "create a new branch" functionality doesn't really belong in your list,
> since branches are created with "git branch". The -b switch is provided for
> checkout because _updating the working copy_ and creating a new branch is a
> very common sequence.

It absolutely does belong in the list. The problem is not simply that 'git
checkout' can do a lot -- it's that the documentation is very hard to scan
_because_ it can do a lot. Adding the -b switch adds to the problem because
now you have to mention how this option interacts with the others (and give
examples of how to use it in the Examples section).

Sure, if I want to create a new branch at a specific revision then the -b
switch saves me a few keystrokes -- but it also makes the documentation for
'git checkout' harder to quickly find what I'm looking for whenever I want to
look up something, even if it's completely unrelated to branch creation.

~~~
aphyr
I always looked at -b this way: git checkout <branch> updates my working copy
to some branch. -b just means "Implicitly create the branch if it doesn't
exist yet."

------
Groxx
I love the SVN brick + merging room analogy.

"Magical" indeed, precious. They wants their code in the trunk, doesn't they,
yes they do. Stupid, fat, filthy geekits, they want to ruin the precious! We
must stop them, we must.

------
dan_sim
They got it right on about Git Airline. I use it but I never understood it
completely.

 _though sometimes they secretly wonder if the Mercurial flight got there
faster_

I think that this airline thingy is the kick in the ass that I needed to
finally at least try Mercurial. I hate git since the beginning but felt like
"I had to use it".

~~~
timwiseman
I am a big fan of mercurial for single-developer projects because at that
level it is extremely easy to setup, learn, and use. With Tortoise HG I was
using the basics effectively long before I got around to reading the manual.

------
CaptainZapp
So where the hell is ClearCase?

Try to google 'hate ClearCase', alas, it's not that bad. Just expensive as
hell, requires iron to run the reservation system of a major car rental
company and a couple dozen adminsitrators to keep it running. This is not much
of an exaggeration.

~~~
dragonquest
Clearcase Airlines is run by one of the largest megacorps in the world and
usually only have business executives flying in them. They are a pretty old
airline whose ownership has changed hands many times over the years, each
owner adding a new carpeting and furnishing layer without removing the old
one.

This resulted in a lot of customers complaining about the speed of the journey
but since its control is under singular management, change has been slow.
There is frequent time lag of messages between the control tower and the
airplane though this does not seem to affect the dependability of the flight.
Its usually considered more reliable than the Sourcesafe airline where the
communication loss between the tower and the airline results in an immediate
stall.

------
tvon
The "there’s one right way to do it" misquoting/misunderstanding of the python
mantra is starting to annoy me.

------
WorkerBee
Nothing from Microsoft? No TFS? They missed a golden opportunity to lay into
Visual SourceSafe too ;0

~~~
ratsbane
If version control systems were airlines VSS would be a bus.

~~~
bobbyi
A bus that always manages to lose your luggage.

~~~
joshu
Bus plunge!

------
jrockway
+1 for the porcelain reference.

------
jimfl
Which version control system would prevent Kevin Smith from checking in code
because he's a "danger to the code base?"

~~~
jff
Git, for going over the 100 MB free Github account? (I know, Git partisans,
Bitbucket has a similar, not much larger limit on free accounts)

~~~
stevelosh
Actually BitBucket gives free accounts 1 GiB of space now:
[http://blog.bitbucket.org/2010/02/11/disk-space-is-cheap-
hav...](http://blog.bitbucket.org/2010/02/11/disk-space-is-cheap-have-some/)

------
cabalamat
They missed out SCCS. Anyone remember that?

~~~
jbronn
A long time ago I had to use some legacy scientific code stored in SCCS repos
on a Solaris server. It's even more arcane than RCS.

