Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50536
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=ofA+suh6fdZKdwoxXnF4SVwAVxnPO8ljCwo22o+ZqgKewwnTFRGl4TuQfXTlh7X2OE
         e8qrW1l4qavZovxS6WWX5oxpIYmzDYewdgmbGffYOyCsi7FdD/OBT6cNTZqfCL8RiWfs
         3HxezAqYhXfNbHcvOD0XepDQkGnwByYGX0H0M=
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.00.1011251512170.4718@kossu.derickrethans.nl>
References: <AANLkTinnOnk2FuxdriyksW4zGGCmauWP7XLBqkTVLMgU@mail.gmail.com>
	<alpine.DEB.2.00.1011251406450.4718@kossu.derickrethans.nl>
	<4CEE7230.9040002@lsces.co.uk>
	<AANLkTimUkFqB-w8kCRJ=k0_HCaToYWm31zo1f9NBFpHm@mail.gmail.com>
	<alpine.DEB.2.00.1011251512170.4718@kossu.derickrethans.nl>
Date: Thu, 25 Nov 2010 07:28:12 -0800
Message-ID: <AANLkTikL1MSyxs8OV3S18YqmdC8Hvd4WtSGztGfdBdiF@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: Ferenc Kovacs <info@tyrael.hu>, Lester Caine <lester@lsces.co.uk>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] git anyone?
From: hermanradtke@gmail.com (Herman Radtke)

>> >> I am not in favour; I will repeat what I just wrote to Davey:
>> >> DVCS is also a lot more egocentric thing, instead of
>> >> collaboration. You want your stuff exposed to as many developers as
>> >> possible instead of walled gardens. It might be easy enough to
>> >> share, but discovery is a lot harder.

Developers can already wall themselves off now with the github mirror.
 Also, taking a peak at the linux dev mailing list I see lots of
collaboration going on.  It makes sense that a developer wanting to
discuss a new feature or patch will push that branch to origin.

What a DVCS does allow for are branches for each specific
project/patch and incremental commits within that branch.  That keeps
project/patch commits together and also side-steps the entire issue of
cherry-picking.  At work we use git and usually have 6 project
branches with competing and interweaving timeframes.  Each developer
has upwards of 50 branches local to them (heck I recently had 105
until I did some cleaning yesterday) that feed the project branches.
We manage this with very few problems and is not something we could do
with cvs or svn.

>> >
>> > Ignoring the problems of actually using github I think this is
>> > exactly the problem we are finding with those projects that have
>> > pushed over to git. MANAGING what is allowed back into some master
>> > copy of the code base is the bit that is a lot more difficult than
>> > with current arrangements. The result is several versions of the
>> > same projects simply because people are doing their own things and
>> > then nobody knows which version to pull from. The release manager
>> > has to un-pick what should be merged and even on a small project
>> > this is time consuming. If everybody with their own agenda for PHP
>> > starts doing their own builds we will end up with even more branches
>> > since they will just be publishing them ;)
>>
>> http://progit.org/book/ch5-1.html
>> I think we could go with either an Integration Manager kind of workflow, or
>> with the Dictator and Lieutenants (that is used for the linux development).
>> either way, with good merging tools, the integrations isn't such of a
>> problem.
>
> Whatever workflow we prefer is not what is guaranteed to happen. I agree
> totally with Lester here. DVCS fragments the development team.

DVCS does not cause fragmentation.  DVCS is a tool.  How a development
team uses that tool is up to them.

I don't think anyone seriously considering a migration to git is
thinking that there are no problems.  However, the problems Lester is
describing are similar to the problems we have now: people checked in
all kinds of changes to trunk and nobody knows how to pick them apart
to make a stable build.  In my experience, managing DVCS is less work
than managing cvs/svn.  Sure, individuals and entire development teams
can shoot themselves in the foot if they use DVCS incorrectly.  But, I
would rather use a sharp tool (like git) than a dull one (like svn).

-- 
Herman Radtke
hermanradtke@gmail.com | http://hermanradtke.com