I'd be happy to put people in touch with members of the team that
handled the Drupal git migration earlier this year. They successfully
migrated > 1 million lines of code with a 10 year history across a few
thousand repositories from CVS to Git without a hitch (at least no hitch
that the outside world saw). That sort of practical experience should
be helpful in determining some of the finer points of how you'd actually
DO that for a project like PHP.
--Larry Garfield
On 8/17/11 3:13 AM, Lester Caine wrote:
At the risk of being criticised again, I will lay out a couple of
problems that need to be addressed as part of making any progress on
DVCS support.
The first question is 'Do we need DVCS?'
The answer is simple - yes - but what and how is not so clear cut.
(Bare with me ...)
This leads on to 'What is stopping using DVCS currently?'
And the answer is in the rfc - "We will not convert the whole SVN
repository at once."
A mirror of the existing SVN repository falls over because of the size.
So would it be possible to break down the base into more manageable
chunks without moving it to DVCS? Modularize the existing code so that
DVCS mirrors are more practical?
It is this area that is probably more important to get agreement on than
selecting a particular DVCS system. The submodule/subrepo handling
process has been relegated to subsequent RFC's, when in reality it is
handling this area which is key to getting a fully DVCS based system
working at all and how the underlying system handles it needs to be part
of the decision process?
The other question I think is a no-brainer. 'Where is a DVCS solution
hosted?'
Choosing a solution simply because github is more popular than bitbucket
did annoy me when other projects made it, but in the case of PHP I don't
think anybody would suggest that the whole repo system would be moved to
one of these? So the master repos would be at dvcs.php.net?
That being the case, with the correct modular structure, then people
should be able to simply clone to their preferred DVCS system, and
commit changes back via karma authentication? I have no doubt that work
in progress would then be appearing on bitbucket, github and private
hosts, but everybody knows where the master codebase can be found.
In hindsight, the SVN move probably took too long to agree on, and
developments in other areas were already at that time pressing on that
process. But at that time DVCS systems were definitely not ready for
handling modular code bases like PHP, and I would argue at the moment
that this is still an area that is not totally developed? Simply
mirroring CVS to DVCS would probably have been a lot easier process to
manage, but we are now 'lumbered' with SVN, so can the SVN experts offer
any ideas to creating a path forward?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
