Re: [Boost-users] What's happened to Ryppl?

Subject: Re: [Boost-users] What's happened to Ryppl?
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-02-02 03:52:57

Attila Feher F <attila.f.feher-AT-ericsson.com> wrote:
> Steven Watanabe wrote:
> [SNIP]
>> Okay. Â Let me just say this once and for all. The thing
>> that really bugs me when people start talking about how
>> wonderful DVCS's are is that as far as I am concerned,
>> *The physical location of the data does not matter much.*
> [SNIP]
>> Just don't do that. Â It sounds to me like you're
>> imposing your DVCS development model on a centralized
>> VCS and trying to keep changes to yourself for a long
>> time. Â If you don't use the tool correctly, it isn't
>> the tool's fault when things break down.
> [SNIP and SNIP]

<schnipp>

> I honestly believe that there is value in the words told about DVCS here. Â And
> I see your point as well. Â Why change if it works for now. Â I just wish you
> have made those points in a more polite manner.

For what it's worth (and not to imply there's anything wrong with what Attila
wrote), I didn't find the quoted passages rude, and I thought Steven made good
points.  Furthermore, while I still disagree with him, I also understand why
Steven feels the way he does.  The beauty of Git eluded me until I had actually
used it a bit, and I wished someone could explain why it was a big deal in terms
that I thought held water logically.

Here is one logically-watertight fact, FWIW:

A *lot* of what I do with a VCS involves looking at history, including other
branches (merges are an example).  When the VCS is Git, those operations are
*fast*, because the repo is local, and because the Git developers make
performance a top priority.

However, I don't expect that alone to change anyone's mind about Git. :-)

Here's something a bit more subjective, but I think also compelling: having to
commit (relatively slowly) to a publicly-visible repository is a disincentive to
exploratory development and a handicap in when your current line of work gets
interrupted.

First, there's the fact that your experimental changes go out to the world. One
could argue that programmers should simply get over the fear that other people
will judge them on the basis of that code, but it's simply human nature not to
want to expose anything but one's best work.  Moreover, especially if, like me,
you prefer to make fine-grained commits, it is slow to negotiate with a server
for each little thing you want to do.

So the incentives associated with SVN encourage you to keep changes on your
local disk, with no logical separation or comment about their meaning until
you're ready to show them.  Working on a fix for something and need to handle an
emergency somewhere else?  Do you check in what you're working on and go back to
a clean state to handle that emergency?  With SVN I almost never did.  With Git
it's easy and fast, and doesn't expose incomplete work to the world, so I always
do.

I still have a boost svn tree with years-old pending changes in it.  I tried to
review them a few times to see what I could commit and what I should discard,
but I get lost each time, because all I have is a wad of modified files without
a record of what I was doing.  Git encourages you to keep track of what you were
doing by allowing you to snapshot your tree and write little notes about it, and
by making it really fast to do so.

So if you wonder why I'm trying to upend Boost's infrastructure and process,
it's because too much has become a disincentive to participation (for me and for
others, though obviously not everyone).

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com