Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39317
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain macvicar.net from 193.227.246.108 cause and error)
To: Lukas Kahwe Smith <mls@pooteeweet.org>
In-Reply-To: <D593DBDF-3DEA-41D1-8DFD-EDBB88B66E2B@pooteeweet.org>
References: <40FEB6C9-9B66-4761-8B9C-0E70158D9962@wanderingknights.org> <d4ad84b50807250033r36f92879r74d0679026626f04@mail.gmail.com> <48898544.5080100@lerdorf.com> <A1337AF2-50A0-415E-B796-259AFC1B51AD@pooteeweet.org> <48898AB0.2030709@lerdorf.com> <FE5F57F4-0861-4CAB-A6E8-5F4DC711BE59@pooteeweet.org> <641132640.20080725114622@marcus-boerger.de> <D593DBDF-3DEA-41D1-8DFD-EDBB88B66E2B@pooteeweet.org>
Message-ID: <94389362-2809-4201-97BF-50073394F709@macvicar.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v926)
Date: Fri, 25 Jul 2008 11:41:13 +0100
Cc: Marcus Boerger <helly@php.net>,
 PHP Developers Mailing List <internals@lists.php.net>
X-Spam_Report: Spam detection software, running on the system "lovelace.midden.org.uk", has
	identified this incoming email as possible spam.  The original message
	has been attached to this so you can view it (if it isn't spam) or label
	similar future email.  If you have any questions, see
	the administrator of that system for details.
	Content preview:  On 25 Jul 2008, at 10:58, Lukas Kahwe Smith wrote: > > On
	25.07.2008, at 11:46, Marcus Boerger wrote: > >>> I mean that if several people
	work on a changeset, that they still >>> might want to have a join central
	repo. Of course dvcs allows direct >>> exchange of patches as well, but it
	might still be a good idea to >>> have >>> this central dvcs repo for historical
	reasons (lets say some stuff >>> is >>> attempted, it is then abandonded
	and then picked up by someone >>> else). >> >>> Also in terms of standardization
	I mean that even core developers >>> can >>> get overwhelmed if they end
	up having to use git here, and hg there. >>> Then again we are still far away
	from having that many different >>> subprojects that need dvcs. >> >> I still
	cannot follow you. Do you even know about these tools? > > I have not used
	any of them enough in practice to really know them > well. > >> If two parties
	use git or hg they are all fine. And everyone else >> is fine >> too because
	they don' t have to learn dcms (btw, it's a distributed >> cms >> as in code/configuraqtion
	management system: >> http://en.wikipedia.org/wiki/Code_management_system).
	Anyway you >> don't want >> to teach for example our documentation group
	to use git or hg. >> Besides the >> fact thaqt there is no windows support
	for git they do not have the >> slightest use whatsoever for local branching.
	Though of course >> anyone who >> is can safely start it's own perfectly
	working local one. > > > The point is: > - re2c experimental work used git
	[...] 
	Content analysis details:   (-4.0 points, 5.0 required)
	pts rule name              description
	---- ---------------------- --------------------------------------------------
	-1.8 ALL_TRUSTED            Passed through trusted hosts only via SMTP
	-2.6 BAYES_00               BODY: Bayesian spam probability is 0 to 1%
	[score: 0.0000]
	0.4 AWL                    AWL: From: address is in the auto white-list
Subject: Re: [PHP-DEV] CVS to SVN Migration
From: scott@macvicar.net (Scott MacVicar)


On 25 Jul 2008, at 10:58, Lukas Kahwe Smith wrote:

>
> On 25.07.2008, at 11:46, Marcus Boerger wrote:
>
>>> I mean that if several people work on a changeset, that they still
>>> might want to have a join central repo. Of course dvcs allows direct
>>> exchange of patches as well, but it might still be a good idea to  
>>> have
>>> this central dvcs repo for historical reasons (lets say some stuff  
>>> is
>>> attempted, it is then abandonded and then picked up by someone  
>>> else).
>>
>>> Also in terms of standardization I mean that even core developers  
>>> can
>>> get overwhelmed if they end up having to use git here, and hg there.
>>> Then again we are still far away from having that many different
>>> subprojects that need dvcs.
>>
>> I still cannot follow you. Do you even know about these tools?
>
> I have not used any of them enough in practice to really know them  
> well.
>
>> If two parties use git or hg they are all fine. And everyone else  
>> is fine
>> too because they don' t have to learn dcms (btw, it's a distributed  
>> cms
>> as in code/configuraqtion management system:
>> http://en.wikipedia.org/wiki/Code_management_system). Anyway you  
>> don't want
>> to teach for example our documentation group to use git or hg.  
>> Besides the
>> fact thaqt there is no windows support for git they do not have the
>> slightest use whatsoever for local branching. Though of course  
>> anyone who
>> is can safely start it's own perfectly working local one.
>
>
> The point is:
> - re2c experimental work used git

We used svn, we converted the 5.3 branch to svn and then did an export  
at the end and merged back to CVS.

>
> - mysqlnd used bzr
>
> If I am developer X and for some reason I wanted to be involved in  
> the re2c and the mysqlnd stuff, then I would need to know both (or  
> atleast have a stable and easy to use bridge between the two).
>
> This is why I am suggesting to "standardize" on a dvcs.
>
> Also as others have made it more clear than I did in my initial  
> post. A central place for people to merge their pages upstream makes  
> it easier for people to join/examine the development (even if the  
> original people have abonded the effort), without having to hunt  
> down people to get their changesets. It might also be a convenient  
> way to prepare before the final push into our central repo. So again  
> it would be useful to have some default space for teams to place the  
> "stable" state of their collaboration.
>
> Finally Lars also mentioned that it might be a good idea to keep a  
> mirror of svn because creating a copy of current svn in some dvcs is  
> not going to be instant. this again suggests it would make sense for  
> us to standardize on a specific dvcs or we have to start offering  
> mirrors for all candidates.
>

With the svn hooks you can keep a mirror of CVS running and make t  
read only apart from commits to the svn repository. Those using  
cvsread would then not notice much difference.

> Hope I am not too far off-base with these observations ..
>
> regards,
> Lukas Kahwe Smith
> mls@pooteeweet.org
>
>
>
>
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Scott