Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:39311 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 61870 invoked from network); 25 Jul 2008 10:00:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Jul 2008 10:00:33 -0000 Authentication-Results: pb1.pair.com header.from=mls@pooteeweet.org; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=mls@pooteeweet.org; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error) X-PHP-List-Original-Sender: mls@pooteeweet.org X-Host-Fingerprint: 88.198.8.16 bigtime.backendmedia.com Linux 2.6 Received: from [88.198.8.16] ([88.198.8.16:45717] helo=bigtime.backendmedia.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 63/51-22699-144A9884 for ; Fri, 25 Jul 2008 06:00:33 -0400 Received: from localhost (unknown [127.0.0.1]) by bigtime.backendmedia.com (Postfix) with ESMTP id 723DE1EBC018; Fri, 25 Jul 2008 10:00:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at backendmedia.com Received: from bigtime.backendmedia.com ([127.0.0.1]) by localhost (bigtime.backendmedia.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csD0H49aukgt; Fri, 25 Jul 2008 12:00:32 +0200 (CEST) Received: from [192.168.80.139] (unknown [195.226.16.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mls@pooteeweet.org) by bigtime.backendmedia.com (Postfix) with ESMTP id 187FE1EBC017; Fri, 25 Jul 2008 12:00:32 +0200 (CEST) To: Marcus Boerger In-Reply-To: <641132640.20080725114622@marcus-boerger.de> X-Priority: 3 (Normal) References: <40FEB6C9-9B66-4761-8B9C-0E70158D9962@wanderingknights.org> <48898544.5080100@lerdorf.com> <48898AB0.2030709@lerdorf.com> <641132640.20080725114622@marcus-boerger.de> Message-ID: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Fri, 25 Jul 2008 11:58:42 +0200 Cc: PHP Developers Mailing List X-Mailer: Apple Mail (2.928.1) Subject: Re: [PHP-DEV] CVS to SVN Migration From: mls@pooteeweet.org (Lukas Kahwe Smith) 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 - 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. Hope I am not too far off-base with these observations .. regards, Lukas Kahwe Smith mls@pooteeweet.org