Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54633
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Mon, 15 Aug 2011 17:55:50 -0400
Message-ID: <0E.B2.21941.5E5994E4@pb1.pair.com>
To: internals@lists.php.net
References: <slrnj3tulc.6vi.dsp@experimentalworks.net>
 <CAKUjMCUirzSjVs7GvaZmWmhx2W=h6OGyOX0YKPnUHztRkZc5xQ@mail.gmail.com>
 <4E3F02E8.2050402@sugarcrm.com> <alpine.DEB.2.02.1108121119420.4043@whisky>
 <CAH-PCH4YO1e-+=+38DrhwUe-nR9akJ+c=64vk0ar3GZGM5YOmw@mail.gmail.com>
 <4E450EB1.6090502@lsces.co.uk> <1313149176.2648.9.camel@guybrush>
 <4E45192C.2090604@lsces.co.uk>
User-Agent: slrn/pre1.0.0-18 (Linux)
Mime-Version: 1.0
Content-Type: text/plain; charset=utf8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Choosing a distributed version control system
 for PHP (or not). Call for Participation.
From: weierophinney@php.net (Matthew Weier O'Phinney)

On 2011-08-12, Lester Caine <lester@lsces.co.uk> wrote:
> Johannes Schlüter wrote:
> > > > Actually the real question here is WHY create a fork on github
> > > > at all? The copy you are working on LOCALLY is the fork that you
> > > > are developing on? Much of the stuff on github and the other
> > > > DVCS server sites is redundant? You only need to publish your
> > > > local changes to other developers who are working with you not
> > > > to the whole world?
> > since i can publish an experimental feature, get it
> > reviewed/tested/improved before pushing it to the main tree.
> >
> > Mind that "other developers who are working with you" is potentially
> > everybody on this list;-)
>
> But that is the point ... if everybody has their own published
> 'experimental feature' repos, syncing those bits we are playing with
> looks like a nightmare?  Surly the point of DVCS is we share via some
> central pot, and these experimental branches exist there? Having to
> keep track of who's bits you are playing with is the messy bit :( And
> it's that which has caused problems with other projects, where
> 'extensions' have grown in secondary repos ... and become the official
> extension. That is what I think people are just trying to flag up.

Actually, it's not a nightmare; it's incredibly easy, and actually helps
keep features and bugfixes more sandboxed, and thus more easily reviewed
and merged.

As an example, let's say I as a developer want to develop feature Y for
the language. I create a new branch locally, and start developing. As I
near a point where it seems ready, I rebase from the canonical
repository, and check to see if any conflicts occur between my code and
what's come in on the main repo. If all looks good, I ask for review,
and, after a few rounds of back and forth and some coding, again rebase,
and then ask for somebody to merge. The nice part about this is it puts
the onus on the individual developers to ensure they have clean patches
-- if a merge request doesn't apply cleanly, you throw it back and ask
them to submit again when it does.

Now, let's say while I'm working on feature Y, I also tackle issues X,
Z, and A. I do each of these in their own hotfix branches. The nice part
is that there's easy, simple segregation between each fix, and I can
move back and forth between the branches quickly and with no bleed-over.

When it comes to the central repo, you have somebody or a team of people
basically reviewing, merging, and pushing in pull requests. A release
master is "king" or "queen" of a particular release branch, and is the
one who decides if/when a feature is merged to that branch.

The main thing is making it clear who is responsible for merging into a
"master" branch, and who is responsible for merging into a release
branch -- in other words, it comes down to processes. And, frankly, the
processes are not terribly unlike the status quo -- the real question is
what version control system is the best fit for that process. DVCS tools
are (generally) optimized for quick branching, ease of merging, and
minimizing commit size -- all of which could potentially benefit PHP
development.

-- 
Matthew Weier O'Phinney
Project Lead            | matthew@zend.com
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc