Re: CVS to SVN Migration

From: Date: Fri, 25 Jul 2008 10:46:37 +0000
Subject: Re: CVS to SVN Migration
References: 1 2 3 4 5 6 7 8 9  Groups: php.internals 
Request: Send a blank email to internals+get-39320@lists.php.net to get a copy of this message
On 25.07.2008, at 12:41, Scott MacVicar wrote:
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.
Ah ok .. the point was just to provide an example that if its a free for all on what dvcs to use, it can make things harder for people that join/examine different experimental branches :) regards, Lukas Kahwe Smith mls@pooteeweet.org

« previous php.internals (#39320) next »