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

Subject: Re: [Boost-users] What's happened to Ryppl?
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2011-02-02 04:12:10

Dave Abrahams wrote:

> 
> 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.

It's true.

> 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.

It's also true. It's also true that git has some features that help with that.
But, it does not mean Boost repository should be git.

I am primarily using git to keep local patches against various projects,
which use Subversion and CVS. In some cases, it's a substantial convenience. E.g. when
a patch review turnaround can be a week, it's nice to put a sequence of patches
on a git branch. Note however, that git is not necessary the only, or the best
answer. Some folks who are way more effective that myself in dealing with patch
series use quilt, and it works just fine desprite not having any hype around.
And, if you prefer git, you can use git-svn just fine. This will solve all your
issues above.

It is true that having Boost use git will make it slightly more convenient to
use git on your computer. However, only slightly more. And the downsides are:

- Transition costs
- Ongoing problems for new folks who are not familiar with git
- Quirky ideas about how you should to version control that git appears
to enforce on its users
- That cherry-pick deficiency
- And, finally, a serious risk that as soon as Boost switches to git, everybody
will get excited, create 100 clones everywhere, and everybody will spends
days sending and merging pull requests, while there will be no official
version. This is of course, a process problem, but given our track record
of ignoring process problems and focusing at not too important discussions,
I bet we would not be able to fix this.

> 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).

Why don't you try git-svn, first?

- Volodya

-- 
Vladimir Prus
Mentor Graphics
[phone]