Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54699
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.186 cause and error)
Message-ID: <4E4D5E30.5070202@lsces.co.uk>
Date: Thu, 18 Aug 2011 19:47:12 +0100
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.19) Gecko/20110420 SUSE/2.0.14-2.2 SeaMonkey/2.0.14
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
References: <4E4B7845.8@lsces.co.uk> <4E4BD968.6060706@garfieldtech.com> <CAEZPtU4cmz2M2OUsgRq=tMUhyge7+0wzbe9hMpoi-RS3SEKXwA@mail.gmail.com> <4E4CC012.2040304@lsces.co.uk> <CAEZPtU5T+n8_eONk6W1UhqwL-eDFJaCM42pQTmSnJJXCbRcwOA@mail.gmail.com> <4E4CE045.4010500@lsces.co.uk> <slrnj4qjsq.6vi.dsp@experimentalworks.net>
In-Reply-To: <slrnj4qjsq.6vi.dsp@experimentalworks.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Choosing a distributed version control system for PHP
 - problems
From: lester@lsces.co.uk (Lester Caine)

David Soria Parra wrote:
> On 2011-08-18, Lester Caine<lester@lsces.co.uk>  wrote:
>> >  Again neither of those seem to be using 'superprojects', just the odd library
>> >  included as a submodule.
> It seems that the statements in the RFC were not clear enough, I'll add some explanation.
> We will very probably not use submodules in php-src anyway. Other module will define
> what's best for them.
Just for the record ... the libreoffice clone I started 9 hours ago is still 
going strong, and I'm estimating that it will finish some time tomorrow 
afternoon, another 20 hours or so. A single huge repo is going to take time to 
handle? Or am I doing something wrong? All I've done at the moment is followed 
the instructions Pierre directed me to ... they were not on the original notes I 
looked at.

> Please talk about the RFC and it's content. If you have a certain problem with a certain
> section in the RFC i'm happy to discuss it. At the moment I cannot see what the topic
> adds to the RFC discussion.
I simply don't see the point of the rfc?
Starting with the drawbacks on SVN ... they were ignored when used as reasons to 
not move from CVS. People had already decided that a move should take place and 
when DVCS was brought up then it was not seen as a reason hold fire since people 
wanted to plough on. Lets not plough on with another change without fully 
understanding the problem?

Many of us are already using DVCS, and so the question is one of how do we link 
from our preferred DVCS system into what ever PHP does. git simply does not work 
for me and so I am already committed to hg. HAVING broken things down into 
subrepos in hg, I can now build projects just using the modules I need, and I 
don't need to carry around lots of unused history. Trying to follow the trees of 
some single repo projects on github and elsewhere can be almost impossible.

> I will clarify some things anyway.
In 'Moving extension from/to core to/from pecl'
'Commits across multiple subrepositories will lead to separate commits.' When 
making a change which affects several modules then the reason for the change 
needs to be properly documented. This is why I say that we need a proper 
management of these changes. A good example in the past was the bugs introduced 
into several of the database drivers by global changes. php_interbase and others 
developed a problem with bolb ID's being corrupted. Trying to track why and 
where changes had been made was a problem, and just being able to isolate the 
one driver and fix that was fun. Had the commits to each driver been separated, 
repairing the damage would have been a lot easier? Changes that create patches 
to hundreds of files in the one commit would seem to be a lot more of a problem 
than distributing those commits, and logging the details of each module affected 
in the base bug/feature report justifying a global change?

Moving on from that ... probably 50% of the 'core modules' are essentially 
optional, so being able to 'pick and choose' the modules you want makes perfect 
sense, much as we all do when selecting modules in the build process. Why do you 
need a combined history across an array of modules? Although I don't see 
anything preventing one being created since all the information is available? I 
flag changes that have a global effect, but the bulk of commits are always 
within a single module. If they affect a second module it may well be that 
something is wrong with the segregation of the activity and that needs to be 
looked at?

-- 
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