Re: [PHP-DEV] CVS to SVN Migration
Rasmus Lerdorf schrieb: Lukas Kahwe Smith wrote: The git and hg integration with svn is also good so any developer who prefers to have a local repository can very easily use either git or hg and easily merge into the central svn repository. However I think we should provide the infrastructure for developers to setup a dvcs. I dont know if we want to standardize on a specific one. But collaboration on exterimental stuff that requires a dvcs should be possible on php.net servers. What do you mean by that? hgsvn and git-svn don't need any server-side support to enable you to work locally and do local git or hg checkins and then sync to the central svn repository when you are ready. -Rasmus It should not be a question of product, but of workflow. An example: A lot of time is needed when porting bugfixes from a stable branch to the development branch and vice versa. In my experience a DVCS reduces this time immense. PHP-SRC consists of a lot of branches (and tags) and the goal should be to port code as easy as possible between different branches. Using a DVCS which is based on a direct acyclic graph (short DAG) can change the way you work with a VCS. Probably most of you who have worked with a DVCS know the technique of DaggyFixing (http://www.venge.net/mtn-wiki/DaggyFixes). Basically it means that a Bugfix is not committed to the revision where it is fixed, instead the Bugfix Graph is inserted right after the feature where the problem occurred and then the merge is propagated to the head revision. If you take SVN and export it locally to a DVCS, then do some coding and reimport your patches, this advantages are probably lost (though I have to admit that I never tried it). Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
On 25.07.2008, at 12:44, Gwynne Raskind wrote: On Jul 25, 2008, at 6:34 AM, Hannes Magnusson wrote: At this point it's clear that moving from CVS to SVN for PHP has become a more or less official project. Has the phpdoc revision/translation problem been looked into/fixed? No, not yet, but it will have to be. I intend for discussion on svn- [EMAIL PROTECTED] For the record, I will more or less ignore discussion that happens on internals@ on the subject; the idea of making a new list was to keep noise about the situation out of the ears of people who don't care. Especially with the 5.3 release coming, the last thing we need is extra noise without any means of categorizing. Just FYI. I moved the original page with the migration work by Gwynne and added a landing page that is supposed to pull together all relevant content (since the conversion of cvs is just one task of many): http://wiki.php.net/vcs/cvstosvnmigration In case anyone has any other documents to store in regards to this general topic it should go into the vcs namespace as well. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
Hello Travis, Friday, July 25, 2008, 9:27:02 PM, you wrote: Hello Marcus; Marcus Boerger wrote: A cvs read-only mirror would be nice to allow the old way of checking out stuff. But there I fail to see the reason to limit our selves to one additional other tool, nor do I see a reason to complicate matters even more by giving people other repositories that we somehow merge or not. SVN works everywhere and other tools can be used on top of it where ppl see that necessary but it is not the way PHP is being developed. Or do you want to change the whole of PHP development at the same time? I don't presume to speak for Lukas here, nor to believe we should standardize on one particular alternative VCS (be it a DVCS or not). I think we should definitely go the SVN route as the only official way to commit to PHP with possibly a read-only mirror on CVS that could be phased out at some point in the future. That said, I think if someone is willing to step up to the plate and offer bootstrap repositories for another VCS and is willing to help support it for those who are interested in using it we would be remiss in turning them down as it's no small undertaking. According to the wiki there are over 270k commits in php-src. Using Mono (90k - 100k commits) and my own experience with smaller repositories (500 - 30k) as a guide, this means that to clone the entire history of PHP via a `git svn clone` command would take nearly a week! Using a bootstrap that is updated nightly, or even weekly, we can cut that process down to 15 minutes. I've already volunteered on the svn-migrations list to work on an unofficial mirror as soon as the SVN import is completed. I would love to see it make its way onto a php.net server so others who are interested can benefit from the upfront work, but will be happy to host it on one of my servers like the current git clone is. Your help for such a git gateway is probably more than welcome ffrom the git lovers. Personally I'd probably prefer HG for the task but who knows. Anyway before we start with that we need to finish the SVN work because else there is nothing to bridge to. And even though Gwynne has already done a ton of work we still need to migrate all scripts. And hopefully we rewrite them all in Python or PHP rather than in Perl which is what we have right now. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
On Fri, Jul 25, 2008 at 5:06 AM, Gwynne Raskind [EMAIL PROTECTED] wrote: At this point it's clear that moving from CVS to SVN for PHP has become a more or less official project. As such, there is a new mailing list isn't better to migrate to git or mercurial ? http://weblog.rubyonrails.org/2008/4/2/rails-is-moving-from-svn-to-git it's faster and better on my opinion (why wasting time to convert later from svn to git ) [EMAIL PROTECTED] for anyone who wants to help with the move. If you're familiar with what I've already done so far (http://wiki.php.net/svnmigration) and want to help, I beg you on my knees to subscribe (send a mail to [EMAIL PROTECTED]) and let us know what you want to do :). It's past time for PHP to make this step a just a little bit further into the future and I hope we can work together to make it happen. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- developer flamerobin.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
marius popa wrote: On Fri, Jul 25, 2008 at 5:06 AM, Gwynne Raskind [EMAIL PROTECTED] wrote: At this point it's clear that moving from CVS to SVN for PHP has become a more or less official project. As such, there is a new mailing list isn't better to migrate to git or mercurial ? http://weblog.rubyonrails.org/2008/4/2/rails-is-moving-from-svn-to-git it's faster and better on my opinion (why wasting time to convert later from svn to git ) We have 1000+ people with commit access, many of whom are not very technical. We need something with mature Windows tools for those folks and something that isn't completely different to their way of working. The git and hg integration with svn is also good so any developer who prefers to have a local repository can very easily use either git or hg and easily merge into the central svn repository. We don't need to be on the bleeding edge of revision control systems. In fact, I prefer to very much be a very very slow follower in that particular area to make sure that all tools are extremely mature by the time we go anywhere near them. The last thing we want to do is slow down PHP development any further by forcing people to fight with a bleeding edge set of tools. When a winner eventually emerges in the de-centralized revision control world and everyone creates tools for all the various platforms, we'll have a look, but I predict that to be years away. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
On 25.07.2008, at 09:48, Rasmus Lerdorf wrote: marius popa wrote: On Fri, Jul 25, 2008 at 5:06 AM, Gwynne Raskind [EMAIL PROTECTED] wrote: At this point it's clear that moving from CVS to SVN for PHP has become a more or less official project. As such, there is a new mailing list isn't better to migrate to git or mercurial ? http://weblog.rubyonrails.org/2008/4/2/rails-is-moving-from-svn-to- git it's faster and better on my opinion (why wasting time to convert later from svn to git ) We have 1000+ people with commit access, many of whom are not very technical. We need something with mature Windows tools for those folks and something that isn't completely different to their way of working. The git and hg integration with svn is also good so any developer who prefers to have a local repository can very easily use either git or hg and easily merge into the central svn repository. However I think we should provide the infrastructure for developers to setup a dvcs. I dont know if we want to standardize on a specific one. But collaboration on exterimental stuff that requires a dvcs should be possible on php.net servers. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
Lukas Kahwe Smith wrote: The git and hg integration with svn is also good so any developer who prefers to have a local repository can very easily use either git or hg and easily merge into the central svn repository. However I think we should provide the infrastructure for developers to setup a dvcs. I dont know if we want to standardize on a specific one. But collaboration on exterimental stuff that requires a dvcs should be possible on php.net servers. What do you mean by that? hgsvn and git-svn don't need any server-side support to enable you to work locally and do local git or hg checkins and then sync to the central svn repository when you are ready. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
On 25.07.2008, at 10:11, Rasmus Lerdorf wrote: Lukas Kahwe Smith wrote: The git and hg integration with svn is also good so any developer who prefers to have a local repository can very easily use either git or hg and easily merge into the central svn repository. However I think we should provide the infrastructure for developers to setup a dvcs. I dont know if we want to standardize on a specific one. But collaboration on exterimental stuff that requires a dvcs should be possible on php.net servers. What do you mean by that? hgsvn and git-svn don't need any server- side support to enable you to work locally and do local git or hg checkins and then sync to the central svn repository when you are ready. 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. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
However I think we should provide the infrastructure for developers to setup a dvcs. I dont know if we want to standardize on a specific one. But collaboration on exterimental stuff that requires a dvcs should be possible on php.net servers. Maybe it's just about having the possibilities for developers to share experimental trees on a php.net side so that people from outside can pull from it easily and not to remember a bunch of urls to get the trees of some developers working on interesting patchsets. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
On 25.07.2008, at 10:25, Lars Strojny wrote: Hi Rasmus, Am Freitag, den 25.07.2008, 01:11 -0700 schrieb Rasmus Lerdorf: [...] What do you mean by that? hgsvn and git-svn don't need any server- side support to enable you to work locally and do local git or hg checkins and then sync to the central svn repository when you are ready. git-svn is really slow when you check out a huge repository. And PHP- SRC will be huge. So it might be worth to export nightly git repos and to provide a space for developers to create personal repositories from that nightly repos for collaboration (think re2c, PDO_MYSQLND, etc. pp.) BTW: I talked to some mercurial developers at a recent google code event here in Zurich. They said that their svn bridging is still not at the same level as that of git, but its being actively addressed. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
Hi, David Soria Parra wrote: However I think we should provide the infrastructure for developers to setup a dvcs. I dont know if we want to standardize on a specific one. But collaboration on exterimental stuff that requires a dvcs should be possible on php.net servers. Maybe it's just about having the possibilities for developers to share experimental trees on a php.net side so that people from outside can pull from it easily and not to remember a bunch of urls to get the trees of some developers working on interesting patchsets. launchpad allows you to create mirror Bazaar repos. The original can be svn or bazaar. This is how a bzr repo from Launchpad is provided, although the main repo is svn. Launchpad registration is free and easy. Best, Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
Hello Lukas, Friday, July 25, 2008, 10:26:59 AM, you wrote: On 25.07.2008, at 10:25, Lars Strojny wrote: Hi Rasmus, Am Freitag, den 25.07.2008, 01:11 -0700 schrieb Rasmus Lerdorf: [...] What do you mean by that? hgsvn and git-svn don't need any server- side support to enable you to work locally and do local git or hg checkins and then sync to the central svn repository when you are ready. git-svn is really slow when you check out a huge repository. And PHP- SRC will be huge. So it might be worth to export nightly git repos and to provide a space for developers to create personal repositories from that nightly repos for collaboration (think re2c, PDO_MYSQLND, etc. pp.) BTW: I talked to some mercurial developers at a recent google code event here in Zurich. They said that their svn bridging is still not at the same level as that of git, but its being actively addressed. I don't care for slow or fast. Becuase only about 10 people out of a 1000 or so will use any bridge to anywhere. We need to keep our fast development for php-src, pecl, pear and docs running while improving our development process at the same time. So far we didn't upgrade anywhere because non of the tools did offer any real advantage for us - PHP. Subversion is the only one that is not 10 or a 100 times more complex. In fact for 99% of our repository users the change will limit to a one time checkout where a dirrerent repository name, uri or whatever they will name it is being used and when having to type svn instead of cvs. And as always one should address the 99% and not the 1%. At leat I for one would prefer not to loose too many contributers along the way. Either way with subversion 1.5 we get not only general svn support for transactions and moving but also merge tracking. Personally the killer feature here is transactions. And I don't think I have to explain why. But whatever, no other tool is able to provide what we want while being mature and working on all platforms at the same timr. This thread again shows the PHP development. A few people wanting to help and endless amounts of people needing to mail anything they ever thought of. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
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 [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
On Fri, 2008-07-25 at 10:26 +0200, David Soria Parra wrote: However I think we should provide the infrastructure for developers to setup a dvcs. I dont know if we want to standardize on a specific one. But collaboration on exterimental stuff that requires a dvcs should be possible on php.net servers. Maybe it's just about having the possibilities for developers to share experimental trees on a php.net side so that people from outside can pull from it easily and not to remember a bunch of urls to get the trees of some developers working on interesting patchsets. Sharing trees can also be done with svn. A repository structure might look something like that: root + active master tees | + trunk | + php 5.3 | \ ... + developer trees | + johannes | | \ my private play ground | \ \ archive + php 5.2 + php 5.1 \ svn 1.5 should allow merging between these tree's, but all such things should be discussed on the other, new list :-) johannes P.S. I'm a git fan boy but see good reasons against it for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
On Fri, Jul 25, 2008 at 04:06, Gwynne Raskind [EMAIL PROTECTED] wrote: At this point it's clear that moving from CVS to SVN for PHP has become a more or less official project. Has the phpdoc revision/translation problem been looked into/fixed? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
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 [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
On Jul 25, 2008, at 6:34 AM, Hannes Magnusson wrote: At this point it's clear that moving from CVS to SVN for PHP has become a more or less official project. Has the phpdoc revision/translation problem been looked into/fixed? No, not yet, but it will have to be. I intend for discussion on svn- [EMAIL PROTECTED] For the record, I will more or less ignore discussion that happens on internals@ on the subject; the idea of making a new list was to keep noise about the situation out of the ears of people who don't care. Especially with the 5.3 release coming, the last thing we need is extra noise without any means of categorizing. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
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 [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] CVS to SVN Migration
Hi Lukas, We have already had several cases in the past where developers have collaborated on a CVS branch. The main reason why this hasn't been common practice is because CVS branching sucks and because some developers didn't feel comfortable with using branches regardless of the tool. I think SVN goes quite far in making development in branches more productive. I therefore see no reason why mysqlnd and re2c collaborators could not just use an SVN branch. There is and has never been a rule not to use branches in the main PHP repository for such collaborations. My 2 Rappen :) Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
Hello Lukas, Friday, July 25, 2008, 11:58:42 AM, you 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 no we usde svn - mysqlnd used bzr I can still contribute to mysql stuff as all that matters is the main repository. If a smaller team forms and decides on bzr or git or hg then they still have to synch with the main repository, be it cvs or svn. We did the same with our re2c development. The advantage of svn over cvs is that we get integration/migration support with the new tools. 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. There is no need to do so. 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 .. A cvs read-only mirror would be nice to allow the old way of checking out stuff. But there I fail to see the reason to limit our selves to one additional other tool, nor do I see a reason to complicate matters even more by giving people other repositories that we somehow merge or not. SVN works everywhere and other tools can be used on top of it where ppl see that necessary but it is not the way PHP is being developed. Or do you want to change the whole of PHP development at the same time? Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
On Fri, Jul 25, 2008 at 5:15 AM, Richard Quadling [EMAIL PROTECTED] wrote: As a windows user my observations/opinions are ... taken with a grain of salt. ;-P Isn't discussion about how to add on to SVN and which tools will be better-suited for development a decade from now counterproductive to the idea at hand? SVN and CVS are the industry standard right now, with SVN being the better-supported and, in many ways, more economical and prudent approach. I'd be afraid that requiring existing and future developers to learn newer technologies would stall several aspects of the project, introduce many new problems, and hinder the advancement of the language as a whole. There's no reason other things couldn't be introduced at a later point, but my personal preference would be to approach the migration one step at a time. Making small bits of progress over time (while simultaneously being able to focus on PHP) seems to be more sensible than trying to radically change everything at once, negating a proven system in favor of what might work better. -- /Daniel P. Brown Better prices on dedicated servers: Intel 2.4GHz/60GB/512MB/2TB $49.99/mo. Intel 3.06GHz/80GB/1GB/2TB $59.99/mo. Dedicated servers, VPS, and hosting from $2.50/mo. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
Hello Marcus; Marcus Boerger wrote: A cvs read-only mirror would be nice to allow the old way of checking out stuff. But there I fail to see the reason to limit our selves to one additional other tool, nor do I see a reason to complicate matters even more by giving people other repositories that we somehow merge or not. SVN works everywhere and other tools can be used on top of it where ppl see that necessary but it is not the way PHP is being developed. Or do you want to change the whole of PHP development at the same time? I don't presume to speak for Lukas here, nor to believe we should standardize on one particular alternative VCS (be it a DVCS or not). I think we should definitely go the SVN route as the only official way to commit to PHP with possibly a read-only mirror on CVS that could be phased out at some point in the future. That said, I think if someone is willing to step up to the plate and offer bootstrap repositories for another VCS and is willing to help support it for those who are interested in using it we would be remiss in turning them down as it's no small undertaking. According to the wiki there are over 270k commits in php-src. Using Mono (90k - 100k commits) and my own experience with smaller repositories (500 - 30k) as a guide, this means that to clone the entire history of PHP via a `git svn clone` command would take nearly a week! Using a bootstrap that is updated nightly, or even weekly, we can cut that process down to 15 minutes. I've already volunteered on the svn-migrations list to work on an unofficial mirror as soon as the SVN import is completed. I would love to see it make its way onto a php.net server so others who are interested can benefit from the upfront work, but will be happy to host it on one of my servers like the current git clone is. -T -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS to SVN Migration
At this point it's clear that moving from CVS to SVN for PHP has become a more or less official project. As such, there is a new mailing list [EMAIL PROTECTED] for anyone who wants to help with the move. If you're familiar with what I've already done so far (http://wiki.php.net/svnmigration) and want to help, I beg you on my knees to subscribe (send a mail to [EMAIL PROTECTED] ) and let us know what you want to do :). It's past time for PHP to make this step a just a little bit further into the future and I hope we can work together to make it happen. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
