Larry Garfield wrote:
Submodules may make sense for PHP/PECL.  I'm not sure.  That would
likely take the form of a series of repositories, one for each PECL
module, much the way Drupal has for its modules.  Then the PHP core
repository would include a submodule reference to the PECL modules that
were considered "in core" at any given time.  Moving a module into/out
of PHP itself is then just a matter of adding/removing submodule
references.  (Drupal does not do that currently for its core-packaged
modules, but in theory we could.)

There are large areas of the core of PHP which are naturally submodules ( subrepo in hg ). Currently we can all build PHP only using those extensions that we need. When I build my own versions, everything db wise other than Firebird is switched off, so all of the extensions that Linux distributions provide as individually loaded modules are naturally submodules in the core structure? Currently I only bother about code in the modules I actually use, so being able to build my own superproject direct from the repo would be useful and I can now even build that on windows.

hg can equally do all of the same stuff as git with all the same points being made. I don't see github as being any + for git simply because I think one of the developments has to be, as Larry says, a privately managed DVCS system so that the access control can be maintained? ( A year ago votes on other projects choose git simply because of github :( ) At that point I do think that hg's design and plugin structure makes it a lot easier to expand? Certainly when it comes to maintaining the Karma system. If people then want a git view as well that can be generated as a mirror? I'm not sure that git supports the same level of interoperability as hg, bazaar and the others, many of which transparently read git repos. But I think that submodule/subrepo is an area where the cross DVCS functionality starts to fall apart. Currently I build an hg superproject calling each git repo rather than using a git repo with submodules. This may be why git wins out again for the base since hg is a lot happier to simply talk to that than the other way around?

The only real disadvantage to hg is having to handle python code to maintain it, people might start converting from PHP ;) Although phphgadmin is a start to improving the php interface support and could be a good start at a fully PHP managed interface to a PHP repo?

--
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

Reply via email to