Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54648
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.26 cause and error)
Message-ID: <4E4BD968.6060706@garfieldtech.com>
Date: Wed, 17 Aug 2011 10:08:24 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <4E4B7845.8@lsces.co.uk>
In-Reply-To: <4E4B7845.8@lsces.co.uk>
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: larry@garfieldtech.com (Larry Garfield)

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?
>