Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58565
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
Received-SPF: pass (google.com: domain of kris.craig@gmail.com designates 10.180.99.100 as permitted sender) client-ip=10.180.99.100;
MIME-Version: 1.0
In-Reply-To: <87zkbwby4d.fsf@gmail.com>
References: <slrnjl54vo.mfm.dsp@experimentalworks.net>
	<CAKOpQSzFq9ZeJRk43Wj2enF2f0g6gdRxT0d25h=KTsH0V4w9xg@mail.gmail.com>
	<87zkbwby4d.fsf@gmail.com>
Date: Sun, 4 Mar 2012 03:31:33 -0800
Message-ID: <CAKOpQSxuXfK4OGab29tKQEKq3_v-_DC-+3xC2rwOr7vF4LRAhQ@mail.gmail.com>
To: jeremiah.dodds@gmail.com
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=f46d04428e5ce8b45f04ba69267f
Subject: Re: [PHP-DEV] Git Migration: Status Update
From: kris.craig@gmail.com (Kris Craig)

--f46d04428e5ce8b45f04ba69267f
Content-Type: text/plain; charset=ISO-8859-1

+1 what Jeremiah said!

I've noticed that people who are accustomed to Subversion tend to go into
Git using the SVN branching mindset.  While that does technically work in
Git, it essentially misses the point.  To illustrate, let's say a person
from the 16th century travelled forward through time to today.  He's been
using lanterns and torches all his life to light dark rooms.  You then hand
him a flashlight, explaining that this new technology is far better.  This
time traveller then proceeds to dip the end of the flashlight in kerosene
and lights it on fire, using it as a torch.

Technically, that time traveller would be able to light the room that way,
but it would essentially negate the point of using a flashlight to begin
with.  Using Subversion branching practices in Git is basically the repo
version of dipping a flashlight in pitch and setting it ablaze.


I count myself lucky in that I started using Git before Subversion.  People
with that background often have an easier time at first because they aren't
burdened with having to un-learn a bunch of "bad habits."


If anyone is interested, I would encourage you to take a look at this:

http://nvie.com/posts/a-successful-git-branching-model/


This is a widely accepted and efficient branching model that I use on all
my projects.  Of course, in PHP's case, it would have to be tweaked to
account for parallel version development (i.e. phasing out 5.3 while
continuing to build 5.4), but that's essentially how it would work.  It
looks like that's also what Jeremiah was referring to (though please
correct me if I'm wrong).

And he is right in saying that it's not nearly as confusing as it looks.
 It's actually really simple once you've grasped the underlying concept.


What does everyone think of implementing an approach similar to this model?
 It would certainly make it much easier to manage in the long-run IMHO.

--Kris


On Sat, Mar 3, 2012 at 11:53 PM, <jeremiah.dodds@gmail.com> wrote:

> Kris Craig <kris.craig@gmail.com> writes:
>
> > Thanks for the update!
> >
> > Quick question:  As far as the branching model goes, are we going to
> stick
> > with the SVN-style of just having a branch for each release version and
> > dumping all the commits directly onto it, or do you plan on switching to
> a
> > more modern Git-style branching model of merging feature sub-branches
> into
> > the parent version branches?  Or has this issue not been discussed yet?
> >
> > --Kris
> >
> >
> > On Sat, Mar 3, 2012 at 1:58 PM, David Soria Parra <dsp@php.net> wrote:
> >
>
> The "idiomatic" way to do this would be to have releases done as tags
> off of the master branch. Other than that, it makes a lot of sense to
> have a branch for major features / versions, and for people to develop
> specific features in their own branch, to rebase changes coming from
> parent branches onto working branches, and then to merge those into
> their respective parent branches after they're done.
>
> I swear that sounds much more complicated than it is. I personally think
> that php as a whole would *greatly* benefit from adopting this sort of
> development model -- it's likely that git-savvy new contributors will
> anyhow, and it makes accepting contributions a hell of a lot less
> painful.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--f46d04428e5ce8b45f04ba69267f--