Subversion considers its future

Its amazing how programmers can't see the forest for the trees.  The two points listed in the
article about why corporations adopt svn utterly miss the point, as the comments later on
explain.

As an open source programmer, DVCS looks to me like a gift from heaven.  When playing with
Debian packages for example, I have to keep track of a whole pile of patches, some from me,
some from others, until they get pushed into the mainline.  Its a nightmare.

Whether the current darling of the DVCS world, git, is a solution to that nightmare is another
matter.  Watching Martin Kraft at LCA 2008 try to use git to solve this problem was
frightening.  After several attempts to demonstrate what he was talking about which all ended
up in a mess, he fired up gitk (which displays a graphical representation of the repository).
Then, after each git command, he checked the graphical representation so he could verify the
command put him where he wanted to be, and if not he reversed it and went down another path.
In the end with gitk's help he got there.  Now Martin is/was a git beginner, and so perhaps
criticising git on this basis might seem a little unfair, and indeed I am sure if he did the
same thing next year it would just roll off his fingers.  But that is not the point.

The point is that Martin is an experienced VCS user, but even so was finding the learning
curve for a DVCS fairly steep.  (Quick check - how many svn sub-commands are there: 30.  How
many git sub-commands are there: 124.)  But Martin like all open source developers has a
considerable incentive to do so - it will make his life much easier.  The same isn't true for
a corporate developer.

A corporate developer gets almost no benefit from a VCS.  Indeed the reverse is usually true -
it just gets in the way.  It means he has to take additional steps to copy source around, it
means he has to add meaningful comments to his commits, and it means his employer can track
what he is doing.  On the other hand its a great boon to the employer - it means they have a
central, secure repository for the code.  It means they can isolate changes of one developer,
and isolate feature branches.  It means they have an audit trail that can tie into their
change management - and on it goes.  The bottom line is that a corporate VCS is imposed by
management.

Forcing the corporate programmer to use and learn a VCS is difficult.  I have done the forcing
a few times - its always accompanied by grumbles.  Forcing them to learn a DVCS would be
dammed near impossible as now they can claim with some justification that its hard to use and
hard to get right.  There would invariably be stuffed up repositories and lost work in the
beginning.  If you have non-programmers (eg engineers) using the DVCS it is impossible - they
simply don't care and don't have any interest in learning.

But if a DVCS was a huge gain to the employer perhaps that wouldn't matter.  It isn't - in
fact the reverse is true.  To share code in a VCS you have to push it into the central
repository.  With a DVCS programmers can pass patches among themselves and ignore the central
VCS entirely.  Worse, they can chose what parts of their history they want to push to the
central repository, and what to omit.  Thus the DVCS actually negates one of the primary
reasons the employer having a VCS in the first place.

So here is a prediction: in the situations where an company is getting third parties to
develop code the company owns, DVCS as we know them won't get much of a foothold.  The
favoured VCS solution's will only allow commits to be pushed to the central repository.  Many
open source projects are also run in the manner, and they also will avoid DVCS's.