Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58584
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.20.128 cause and error)
Message-ID: <4F539B2B.9050308@lsces.co.uk>
Date: Sun, 04 Mar 2012 16:41:15 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120215 Firefox/10.0.2 SeaMonkey/2.7.2
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
References: <slrnjl54vo.mfm.dsp@experimentalworks.net> <CAKOpQSzFq9ZeJRk43Wj2enF2f0g6gdRxT0d25h=KTsH0V4w9xg@mail.gmail.com> <87zkbwby4d.fsf@gmail.com> <CAKOpQSxuXfK4OGab29tKQEKq3_v-_DC-+3xC2rwOr7vF4LRAhQ@mail.gmail.com> <4F536486.6050801@lsces.co.uk> <87aa3wqv6u.fsf@gmail.com>
In-Reply-To: <87aa3wqv6u.fsf@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Git Migration: Status Update
From: lester@lsces.co.uk (Lester Caine)

jeremiah.dodds@gmail.com wrote:
> I hope that clarifies things a bit. It definitely doesn't make grokking
> things a whole lot easier, and it is certainly *possible*  to follow a
> very svnish workflow using git (and may sometimes make sense to,
> although I am struggling to thing of such a time).

I've been using Hg myself for the 'DVCS' style of working. This allows me to 
publish my own ports of things which others can follow, but from which I can 
push things back to the original project as required. I'm still not convinced 
that the 'production' branches such as PHP5.3 can be run without some element of 
management, although of cause a release will still be packaged as a tarball set 
and then frozen. On Hg I just pull a particular tarball ... such as PHP5.3.10 
... as I require it direct from the repo but some of the projects I am working 
with have now lost the 'master' codebase simply because groups of developers are 
now doing their own thing. The overall flexibility of DVCS still needs a mindset 
of maintaining a code base that follows the master route plan? Which may well be 
a more 'svnish' way of working when testing and committing production ready code?

The question I think that needs to be asked is 'should experimental development 
branches exist in the master code base?' all very easy to do with DVCS, but is 
it practical. Does it not make sense to clone the experimental work from another 
source, and keep the main codebase tidy with just proven pushes that follow the 
production path. There is nothing actually stopping someone producing their own 
private branch and sharing that while it is being developed, just pushing the 
results back to the relevant master branch when development work has been completed?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php