Re: GIT vs Other: Need argument

["Michael K. Edwards" <medwards.linux@gmail.com>]

Suppose I were dealing with career software developers, backed by real
money, who also happened to be intelligent, thoughtful people, and I
wanted to make the case for git vs. CVS/SVN.  I'd start by handing
them copies of the O'Reilly Perforce book and suggesting that they
read it cover to cover.  Focus on the chapters on how well organized
development and release branches, and good tracking of feature/fix
propagation among them, can help you cope with the vagaries of
real-life software development.

Then I'd explain the relative merits of Perforce and git -- on one
hand, availability and quality of documentation, training, tech
support, and Windows versions; on the other hand, a genuinely
distributed design, which means that you don't need psychic powers to
arrive at a sane branch structure.  Specifically, git's design makes
private branches ultra-cheap for the developers that use them and
zero-impact on the release infrastructure, and the integrity of
_content_ and _history_ doesn't rely on any resemblance between my
branch layout and yours.  Speed, scalability, zero license cost, and
the hypothetical ability to hack on it yourself are nice too, but
they're basically fringe issues unless you're so big that you can't
just throw money at the problem -- in which case they're still fringe
issues because you're the enterprise-customer tail that wags the
vendor dog.  (If you're big _and_ cash-poor, or if you're stuck on a
VC system so badly designed that no amount of money thrown at the
problem will help, you have a different problem.)

If you do this right, it should be clear that CVS is in the dust on
all fronts and SVN doesn't (AFAICT) have any advantage over Perforce
that git doesn't have more of.  You might also mention that git was
designed by Linus to systematically not suck, and has been
successfully handed over to a strong maintenance/enhancement team that
works in public view.  And Linus is still here policing to keep
suckage from creeping in.  ;-)  The hypothetical smart developers will
then agree to go with either Perforce or git, depending on which the
people who have to do the hard work -- release managers and the IT
Morlocks -- are most comfortable with.

If you take this route, be prepared to wind up with Perforce.  It's
got its weaknesses, and I prefer git myself, but you could certainly
do a lot worse.  I'm not as anti-SVN as Linus, but there aren't many
workflows for which I would recommend it over Perforce.  Personally, I
wouldn't voluntarily introduce any other version control system into
the discussion, because the others that I've used in the course of one
day job or another suck massively by comparison, and the ones I
haven't used (or have only toyed with) don't appear to have any
compelling advantage over git.  (Having _marginally_ better
documentation isn't much to brag about).

Until someone writes a good book on git and sets up shop as a
commercial support organization, presenting Perforce vs. git as a
classic buy/build decision is probably the best you can do.  (You
don't have to "build" git, of course, but you'd have to build your own
in-house training and tech support capability.)  I say this as someone
who routinely sits in the "release manager" chair, uses git by choice,
and is currently suffering the pain and agony of migrating a perfectly
good git-based integration process to Perforce, simply because it
appears to be the right thing for this developer organization.
(Doubtless this colors my opinion du jour.)

Cheers,
- Michael