David Soria Parra wrote:
On 2011-08-18, Lester Caine<les...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
