Re: Two More Very General Consulting Question
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--232016332-248942270-1323547967=:25348
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
On Fri, 9 Dec 2011, Arved Sandstrom wrote:
On 11-12-08 12:04 PM, Tom Anderson wrote:
On Wed, 7 Dec 2011, Arved Sandstrom wrote:
On 11-12-07 07:57 PM, Arne Vajh?j wrote:
The distributed part is great for code that is being worked on by
completely independent organizations (read: large open source
projects).
But most people do not really have that need.
I agree that there are plenty of scenarios that benefit from a
distributed VCS. But a whole bunch don't.
It's true that a great many projects don't need the anarchic
fully-distributed mode of operation that DVCS allows.
But the thing that DVCS gives you that is invaluable to everyone,
everywhere, is local commits.
Tom, no need to sell _me_, I am sold already. :-)
Ah, sorry. When you wrote:
I agree that there are plenty of scenarios that benefit from a
distributed VCS. But a whole bunch don't.
I assumed that meant that you didn't think DVCS had universal benefits.
That's why I have tried three times in as many years to introduce a DVCS
in a real work environment. Each time it's been a SVN shop (which is
part of the problem, they've already got SVN).
I'll tell you why it's failed:
1. It's (legitimately) hard to convince a client that a centralized DVCS
model is significantly better than a SVN setup. It has to be
_significantly_ better because they are facing a migration of history
(History is super-important in these organizations. It is how you locate
scapegoats.)
There are conversion tools which will import repositories, with history,
from other VCSs into various modern DVCSs; we used cvs2git to convert some
of our projects from CVS to Git, and it worked pretty well. There was a
bit of manual faffing about, though - i think the conversion took about a
day to get right. I believe the conversion from Subversion to Hg/Git is
much smoother than from CVS, because Subversion at least has atomic
commits.
Nonetheless, i recognise that conversion is not necesssarily
straightforward. I've seen questions on the Mercurial mailing list about
people having real trouble with it - although of course that's
self-selecting, as the people for whom it goes smoothly don't post!
2. Very few arguments that have to do with benefits for _developers_ are
important. You don't have to convince developers, you have to convince
managers.
2. Only the developers amongst the client personnel understand your
"local commits" argument, or the other one (better branching/merging
than SVN). Problem is, very few of the managers get it, and _they_ are
the ones that need to be convinced.
I've encountered my share of client managers that actually don't see
your description of local commits as being a good thing, unlike you or
me or most developers. To them that all sounds like coders wasting time
at best, and unsupervised work at worst.
Interesting and depressing. Why on earth are people who don't understand
programming making decisions about programming tools? These sound like
very sick organisations. Plenty of those around, of course!
In fact I'm satisfied that hg/git are always at least as good as svn,
and usually better.
It's simply that I have yet to encounter a team environment where the
managers bought this.
This is just baffling to me. These people make software, right? So it's in
their interest to have the best tools for making software? This is like
shipwrights preferring to stick with forge welding rather than adopting
arc welders.
But, yes, it happens. On my last big external project, we used CVS; we
pointed out that CVS wasn't very good, and suggested moving to Git/Hg, and
the client came back and suggested moving to their corporate standard,
which was Team Foundation Server. We quickly backtracked and said that CVS
was just fine. Ugh.
tom
--
Work alone does not suffice: the efforts must be intelligent. -- Charles
B. Rogers
--232016332-248942270-1323547967=:25348--