Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54915
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.26.188 cause and error)
Message-ID: <4E55F1CB.5070201@lsces.co.uk>
Date: Thu, 25 Aug 2011 07:55:07 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110815 Firefox/6.0 SeaMonkey/2.3
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
References: <slrnj5appg.6vi.dsp@experimentalworks.net> <4E556A0B.4010406@sugarcrm.com> <4E556AC0.5070706@gmx.net> <4E557F52.2040008@lsces.co.uk> <slrnj5b0qp.6vi.dsp@experimentalworks.net> <CAMWw8k9boYzj5Tk-Z3OVtMry_Ksu0+V5miVTfGArfsQMO8jrpg@mail.gmail.com>
In-Reply-To: <CAMWw8k9boYzj5Tk-Z3OVtMry_Ksu0+V5miVTfGArfsQMO8jrpg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [VOTE] Choosing a distributed version control system
 for PHP
From: lester@lsces.co.uk (Lester Caine)

Gwynne Raskind wrote:
> On Wed, Aug 24, 2011 at 19:03, David Soria Parra<dsp@php.net>  wrote:
>> >  Those wanting to use git and git workflows have a disadvantage when we stay with SVN.
>> >  Choosing a VCS happens from time to time and sometimes your favorit is not the winner.
>> >  I personally would love to see PHP moving to hg, but if more people like git more, the
>> >  hg people have to deal with it.
> Agreed on both counts.
It _is_ nice to see that I am not alone in preferring hg ...
Sometimes it does seem that I'm in a minority of 1.

>> >  The RFC points out that there will be modules. We will_not_  copy the current SVN
>> >  history into one big repo. In fact having everything, pecl, php-src and co in one
>> >  repository does not make sense.
> The original plan called for the SVN repo to be split up at some point
> in the future, but DVCS gained traction and SVN went without any
> attempts by anyone to put a proper workflow of any kind in place.
And I think this is the point.
With the right structure in place then it _will_ be easier for cross dvcs 
working. The current plan calls for all of php-src to be a single repo, with 
rules for moving extra modules in and out. That is the single repo I am 
referring to and potentially it will be as unwieldy as the libreoffice setup? It 
_is_ about time that splitting things up was considered in a little more detail 
so we can work on every module with the same ease as 'extra' extensions are now 
currently managed? Even the argument that one needs to see all the history at 
once has the alternative view that just seeing commits for a single module would 
be helpful?

( Note Pierre - I'm not using upper case for emphasis - I started text messaging 
when the printers only had upper case so I'm still learning these newfangled 
ways :) )

-- 
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