Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #10619

Re: Two More Very General Consulting Question

From Arved Sandstrom <asandstrom3minus1@eastlink.ca>
Newsgroups comp.lang.java.programmer
Subject Re: Two More Very General Consulting Question
References (3 earlier) <sdrud79e4044ni5uv0tnlna41q3eo890oh@4ax.com> <alpine.DEB.2.00.1112071851130.1589@urchin.earth.li> <4edffd56$0$286$14726298@news.sunsite.dk> <mBTDq.11783$cG.7766@newsfe14.iad> <alpine.DEB.2.00.1112081541440.15036@urchin.earth.li>
Message-ID <SMlEq.17211$JE1.11242@newsfe21.iad> (permalink)
Organization Public Usenet Newsgroup Access
Date 2011-12-09 06:53 -0400

Show all headers | View raw


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:
>>> On 12/7/2011 1:58 PM, Tom Anderson wrote:
>>>> On Wed, 7 Dec 2011, Roedy Green wrote:
>>>>> see http://mindprod.com/jgloss/subversion.html
>>>>> http://mindprod.com/jgloss/tortoisesubversion.html
>>>>
>>>> I would say that in this day and age, it is no longer appropriate to
>>>> suggest Subversion. Subversion was the best tool available for a
>>>> long time, and it is still perfectly serviceable, but there are
>>>> better tools available now; projects using it can keep using it
>>>> without worry, but there is no reason for a new project, or a
>>>> project adopting a new source control system, to start using it.
>>>
>>> VCS is an area where fashion often seems to overshadow
>>> facts.
>>>
>>> Today with hg and git then SVN is suddenly so oldfashioned - you can
>>> not use a non-distributed VCS without being considered stone age.
>>>
>>> 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'm with you on this, Arne. You beat me to it actually. 100 percent of
>> the version control scenarios that I have encountered in business in
>> over a decade require a "central" or "master" repository and an
>> official keeper of the flame. Branches have to be strictly decreed and
>> controlled, lest anarchy result. If git or Mercurial were used in
>> place of SVN, the manner in which they'd have to be used would offer
>> zero benefits over SVN.
>>
>> I agree that there are plenty of scenarios that benefit from a
>> distributed VCS. But a whole bunch don't.
> 
> Incorrect. Have either of you actually used a DVCS for any length of
> time on a team project?

In order to acquire facility with Mercurial and Git I use them myself,
on my own work (which may be real work, but doesn't involve anyone
else). I've used Mercurial for about 3 years, have used Git less and
maybe for about 2 years.

I haven't done any open source teamed projects within the past few
years. There have been zero opportunities to use Mercurial or Git on the
job, *with a team*. I have actually tried, three times in as many years,
to make one or the other happen.

> It's true that a great many projects don't need the anarchic
> fully-distributed mode of operation that DVCS allows. In fact, the only
> one i know of that really uses it is the Linux kernel; even other open
> source projects using DVCS have a fairly centralised workflow.
> 
> But the thing that DVCS gives you that is invaluable to everyone,
> everywhere, is local commits. You can work, commit, work, commit, work,
> realise you've gone wrong and roll back to your last commit, work,
> commit, work, have an idea, commit, try something experimental, learn
> something, roll back to your last commit, work, commit, and so on. All
> locally, without having to push up to the server, make a zip file, make
> a patch, or do any other monkeying about. All inside the version control
> system.
> 
> It is a massively useful thing to be able to do.

Tom, no need to sell _me_, I am sold already. :-) 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 [1];

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.

> Arved mentioned that "branches have to be strictly decreed and
> controlled, lest anarchy result", and that's true, but with one
> qualification - it's true of branches *on the server*. People can make
> whatever branches they fancy locally, as long as they don't trouble
> anyone else with them. That can be useful too, on occasion.
> 
> My team moved over to Git a while ago. We have a traditional centralised
> workflow: we work locally, and push and pull to a central server. We
> don't push and pull to each other. Even for us, a DVCS has been a great
> tool.
> 
> Even if you don't make use of the new powers bestowed on you by a DVCS
> (which would be a great mistake), the current crop of DVCSs offer
> evolutionary improvements on Subversion. They don't need a server, so
> they're easier to set up and manage. They make creating new repositories
> much easier. They're faster. They are, incredibly, usually more compact
> (a Hg/Git repository + working copy is usually smaller than a Svn
> working copy alone - recall that Svn stores a pristine, uncompressed,
> copy of each and every file). They don't litter your working copy with
> millions of secret directories.
> 
> The only downside is that the graphical tools, and integration with
> other systems, is not always as good as for Subversion. But note that
> "not as good" means "80-90% as good". I use Git and Mercurial through
> their Eclipse plugins, and they are basically as good as the Subversion
> or CVS plugins. They each have a few warts, but they are purely cosmetic.
> 
> So, no, the noise about DVCS is not fashion. It is firmly grounded in
> facts.
> 
> tom

Again, _I_ agree with you 100 percent. But Tom, if you read what I
originally wrote, I referred to "business scenarios that I have
encountered", "the manner in which they'd have to be used", and things
of that nature. I wasn't referring to technical superiority of hg or git
over svn, or lack thereof, or vice versa. 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. I've made three attempts in as many years;
everyone else I've worked with in the past 5 years, say, would have been
as difficult to convince as those three teams.

And bear in mind that quite a few of the arguments in favour of DVCS,
unless pitched very carefully (and sometimes de-emphasized), either
don't interest managers, or they don't like what they hear. I've also
encountered a couple of organizational version control types who have to
be carefully talked to so they don't feel threatened by "developer
empowerment", and once you've semi-successfully done that then they
don't care enough about DVCS to be champions either.

Let me put it this way, and maybe this helps to make my point: "they
make creating new repositories much easier", as you mentioned above, is
_not_ a selling point in many client environments. There is zero appeal
to many managers of developers being able to make repositories, and
there can be substantial pushback to features like this. To many
managers the features of DVCSs that you or I (or other with-it
developers) like are negative selling points, because they interpret
those as leading to lack of control and lack of visibility.

Sooner or later I'll succeed in getting a client organization
interested, and interested for the right reasons. But it hasn't happened
yet.

AHS

1. History is super-important in these organizations. It is how you
locate scapegoats.

Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Two More Very General Consulting Question Novice <novice@example..com> - 2011-11-30 21:00 +0000
  Re: Two More Very General Consulting Question Martin Gregorie <martin@address-in-sig.invalid> - 2011-11-30 21:45 +0000
    Re: Two More Very General Consulting Question Novice <novice@example..com> - 2011-11-30 23:00 +0000
      Re: Two More Very General Consulting Question Martin Gregorie <martin@address-in-sig.invalid> - 2011-12-01 03:06 +0000
        Re: Two More Very General Consulting Question Novice <novice@example..com> - 2011-12-06 15:24 +0000
          Re: Two More Very General Consulting Question Martin Gregorie <martin@address-in-sig.invalid> - 2011-12-06 20:59 +0000
      Re: Two More Very General Consulting Question Roedy Green <see_website@mindprod.com.invalid> - 2011-12-07 05:45 -0800
        Re: Two More Very General Consulting Question Tom Anderson <twic@urchin.earth.li> - 2011-12-07 18:58 +0000
          Re: Two More Very General Consulting Question Arne Vajhøj <arne@vajhoej.dk> - 2011-12-07 18:57 -0500
            Re: Two More Very General Consulting Question Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-07 20:33 -0400
              Re: Two More Very General Consulting Question Tom Anderson <twic@urchin.earth.li> - 2011-12-08 16:04 +0000
                Re: Two More Very General Consulting Question Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-09 06:53 -0400
                Re: Two More Very General Consulting Question Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-09 12:51 +0000
                Re: Two More Very General Consulting Question Lars Enderin <lars.enderin@telia.com> - 2011-12-09 17:26 +0100
                Re: Two More Very General Consulting Question Martin Gregorie <martin@address-in-sig.invalid> - 2011-12-09 23:12 +0000
                Re: Two More Very General Consulting Question Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-10 12:00 +0000
                Re: Two More Very General Consulting Question Tom Anderson <twic@urchin.earth.li> - 2011-12-10 19:53 +0000
                Re: Two More Very General Consulting Question Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-11 00:04 +0000
                Re: Two More Very General Consulting Question Tom Anderson <twic@urchin.earth.li> - 2011-12-10 20:12 +0000
                Re: Two More Very General Consulting Question Jim Janney <jjanney@shell.xmission.com> - 2011-12-12 03:05 -0700
                Re: Two More Very General Consulting Question Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-12 06:39 -0400
            Re: Two More Very General Consulting Question Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-12-07 20:55 -0600
              Re: Two More Very General Consulting Question Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-09 10:42 +0000
        Re: Two More Very General Consulting Question Arne Vajhøj <arne@vajhoej.dk> - 2011-12-07 18:48 -0500
    Re: Two More Very General Consulting Question Roedy Green <see_website@mindprod.com.invalid> - 2011-12-07 05:43 -0800
  Re: Two More Very General Consulting Question Arne Vajhøj <arne@vajhoej.dk> - 2011-12-02 20:15 -0500
  Re: Two More Very General Consulting Question Roedy Green <see_website@mindprod.com.invalid> - 2011-12-06 16:45 -0800

csiph-web