

Martin Fowler's unscientific agglomeration of opinion on version control tools - adam-_-
http://martinfowler.com/bliki/VersionControlTools.html

======
mbrubeck
_"I used to hear people say good things about Perforce, but now the feeling
seems to be that it doesn't have compelling advantages over Subversion, let
alone the DVCSs."_

Perforce still has better support for branches than Subversion does - in
particular, it has robust support for repeated merges between branches.
Subversion 1.5 added "merge tracking" which is supposed to address this
problem, but in my real-world use Subversion still failed relatively often at
repeated merges and the recovery process is tedious and annoying.

On that particular project we ended up switching to git, but I would
definitely choose p4 over svn for use cases (like very very large
repositories) where they are both better than git or hg.

~~~
btilly
The biggest advantage that Perforce has is better performance with large code
bases than subversion, git, or mercurial.

My guess is that most of us don't work with large and active enough code bases
for this to matter. But if you do, consider Perforce.

~~~
yason
These said large code bases are usually much less of code and much more of
binaries, test images or media streams, complete devtool suites, arch
compilers, and almost anything that generally would require less version
control and more availability control.

In other words, stuff you would actually want to live on a network drive or
some other sharing mechanism. But if it's easy enough to shove 10 gigabytes to
Perforce, it will happen.

~~~
InclinedPlane
For some of these things, sure. But if you put your compiler tools, external
binary references, etc. on some share somewhere outside of version control you
will find that when you go to create a patch for some older release you are
well and truly effed. Being able to sync and build with nothing but a bare OS
and the relevant source is a HUGE benefit when you have to support older
releases on the level that, say, Microsoft does.

~~~
yason
It is still the wrong solution.

Disk space is cheap and what you really want is _access to cumulated,
unchanged old versions_ \-- not version control: you generally don't diff or
merge between compilers or test images.

Instead, you can store builds of each and every gcc version you've ever used
on a network disk with very little money and then properly use the version
control system to have the different revisions of the source code point to the
correct set of tools and resources.

It's like a persistent data storage with good accessibility and no delete
command. This is the only real reason why people abuse their version control
system with huge binaries and it's the only reason I can think of. I shall bow
to anyone who has the guts to refuse to abuse and do it properly instead.

------
jmount
I would suggest a different checklist to pick version control systems. Point
one my list would be: "does the system preserve or damage your original?" CVS
and SVN both fail on this by writing dot files in each and every directory of
what you are trying to manage (breaks some non-compiler applications)- so I
would lean more to Git, Mercurial and BZR.

------
Quarrelsome
TFS is not that bad... the issue is that you have to pay through the teeth to
have it and it is not that good.

When it comes out of the box as a bag of bits that you're going to have to
configure, hack and code for hours to get what you want you sometimes wonder
why you didn't just go SVN + Cruise Control.

For the record, I just wanted my test pass/fails to be emailed to us in a
NUnit gui way (red + green). Maybe i'm stupid but that took way too long for a
tool that costs so much.

~~~
nobbynutz
TFS has some redeeming qualities when looked at as part of a holistic software
development platform - bug tracking, work items ect. but purely as a source
control system it is bad.

Day to day experience is just friction, friction, friction.

And guess what keeping source control and your IDE seperate is actually a good
idea. Also why do I care that Alex down the hall has opened a file - what am I
supposed to do with that information...

~~~
Quarrelsome
"And guess what keeping source control and your IDE seperate is actually a
good idea. "

Too true. Killing time watching your IDE lock up is not fun. Nor is the fact
that _some_ IT departments still haven't performed the upgrade from TFS 2005
_unservicepacked_

.. ..

 _cries_

------
adam-_-
If you can't be bothered to read the whole article, he recommends (based on
anecdotal evidence) subversion, git and mercurial.

------
nocman
Wow, the article says "Historically git worked poorly on Windows, poorly
enough that we'd not suggest it. This has now changed, providing you run it
using msysgit and not cygwin.". I find that interesting, and have 2 comments:

1) friends don't let friends use Windows without Cygwin :-D

2) I've been using git _under Cygwin_ on Windows XP since mid 2007, and have
_never_ thought that it worked poorly. In fact I would say that it has always
worked beautifully.

Perhaps the problem(s) with Cygwin git only rear their ugly heads on multi-
developer projects. My experience has all been on single-developer projects.

------
crs
When I first started using clearcase I hated it. Now many years later, I
really appreciate the power it brings to the table. Sure it has negatives just
like all vc tools too, but the easy branching, dynamic vs snapshot views,
automatic merging, the ability to merge directly from a fellow developers
views, etc. has really made my team more productive. However I will say that
it takes considerably more expertise to setup and maintain that something like
svn or git. So there is the added expense of having full time clearcase
admins.

------
keefe
"Subversion encourages a simple central repository model, discouraging large
scale branching. In an environment that's using Continuous Integration, which
is how most of my friends like to work, that model fits reasonably well. As a
result Subversion is a good choice for most environments."

...using continuum you can just plug in a POM with a git connector and no
trouble with CI and git...

~~~
easp
I think you missed the point, which is that Subversion discourages branching,
which is fine, because most of the people he knows do CI. His point is not
that you can't do CI with GIT.

~~~
keefe
My point was that I don't see how the two are related - if you're building off
a branch you can still write a pom that builds your particular branch and the
rest of the trunk code and gives you all the benefits of CI.

------
InclinedPlane
This review (at least it's admittedly unscientific) suffers from a common
problem of many critiques of software development practices: a lack of
appreciation for diversity. Software development spans a much wider range of
conditions than almost any other human activity, scaling from a lone developer
working part-time on a personal project up to teams of thousands of devs and
testers working on billion dollar or perhaps even life-critical software.

Software development efforts can span 6 or more orders of magnitude
difference, and can differ in character enormously (such as between a
scheduled release cycle of unpatchable, life-critical software vs. a
constantly updated web site). Yet despite this huge diversity, most
commentators insist on ignoring it and giving blanket advice as if it were
equally applicable to every development effort in the history of the Universe.

The various drawbacks and benefits of different source control tools will
matter differently to teams of different scales and processes. For some teams
SVN may make sense, for some it may not be even remotely feasible. I've heard
of teams that could not use git because of scaling issues (shocking as that
may sound).

It's hard to take advice seriously that doesn't acknowledge these issues. It's
no different than someone talking about web infrastructure and saying that the
best solution is php/apache and mysql running on two separate servers. That
may be a fine solution, but it's overkill for some scenarios and unsuitable
for a lot of other scenarios. Sometimes you need a thousand servers, sometimes
you only need a single 128mb ram VPS, sometimes you need scala or erlang,
sometimes you don't need anything more than static html, sometimes you need a
REST backend, sometimes you don't, sometimes you need nosql, sometimes you
don't. What works for amazon.com may not be applicable to a personal vanity
page or to twitter or google or paypal.

------
ThinkWriteMute
I'm waiting for someone "popular" to realize how awesome Fossil is. Subv, Git,
and Merc can all blow me.

~~~
mikebo
What does fossil do that git or hg don't? I'd love to hear some real world
examples.

~~~
ellyagg
It's a one file install. You can easily run it behind firewalls. It has built-
in wiki and issue tracking. You can run it from a jailed host; it requires no
access to apache config, it has its own server. You can give users accounts on
it. You can run it in autosync mode, where everyone's changes are sync'd
through a central repo, or you can use manual merge for disconnected use. It
uses the battle-tested sqlite as its transactional local store. It is designed
to optimize the author's preferred workflow, so if you agree with him in
principle, you'll like its ui. Like, e.g., git, it uses SHAs for "artifact"
tracking; the sqlite db can be rebuilt from the canonical artifacts. I haven't
looked for any comparisons, but it's extremely efficient space- and bandwidth-
wise. It's written in SQL, which is semantically efficient, so it's easy to
understand how it works.

