# CVS to SVN Migration - Thread: https://externals.io/message/39291 - Original archive: https://news-web.php.net/php.internals/39291 - Started by Gwynne Raskind on 2008-07-25T02:06:20+00:00 - Messages: 28 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/39291.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #39291 — Gwynne Raskind — 2008-07-25T02:06:20+00:00 URL: https://externals.io/message/39291#39291 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 for anyone who wants to help with the move. If you're familiar with what I've already done so far () and want to help, I beg you on my knees to subscribe (send a mail to ) 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." --- ## #39296 — marius popa — 2008-07-25T07:33:19+00:00 URL: https://externals.io/message/39291#39296 · In reply to: #39291 On Fri, Jul 25, 2008 at 5:06 AM, Gwynne Raskind 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 ) > for anyone who wants to help with the move. If > you're familiar with what I've already done so far > () and want to help, I beg you on my knees > to subscribe (send a mail to ) 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." > > > -- > > > > -- developer flamerobin.org --- ## #39298 — Rasmus Lerdorf — 2008-07-25T07:48:20+00:00 URL: https://externals.io/message/39291#39298 · In reply to: #39296 marius popa wrote: > On Fri, Jul 25, 2008 at 5:06 AM, Gwynne Raskind > wrote: > > […] > 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 --- ## #39299 — Lukas Kahwe Smith — 2008-07-25T07:52:22+00:00 URL: https://externals.io/message/39291#39299 · In reply to: #39298 > marius popa wrote: > > […] > > 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 mls@pooteeweet.org --- ## #39302 — Rasmus Lerdorf — 2008-07-25T08:11:28+00:00 URL: https://externals.io/message/39291#39302 · In reply to: #39299 Lukas Kahwe Smith 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. 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 --- ## #39303 — Lukas Kahwe Smith — 2008-07-25T08:15:08+00:00 URL: https://externals.io/message/39291#39303 · In reply to: #39302 > Lukas Kahwe Smith wrote: > > […] > > 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 mls@pooteeweet.org --- ## #39304 — Lars Strojny — 2008-07-25T08:25:19+00:00 URL: https://externals.io/message/39291#39304 · In reply to: #39302 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.) cu, Lars --- ## #39305 — David Soria Parra — 2008-07-25T08:26:20+00:00 URL: https://externals.io/message/39291#39305 · In reply to: #39302 > > […] 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. --- ## #39306 — Lukas Kahwe Smith — 2008-07-25T08:26:59+00:00 URL: https://externals.io/message/39291#39306 · In reply to: #39304 > Hi Rasmus, > > Am Freitag, den 25.07.2008, 01:11 -0700 schrieb Rasmus Lerdorf: > [...] > > […] > > 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 mls@pooteeweet.org --- ## #39307 — Andrey Hristov — 2008-07-25T09:11:49+00:00 URL: https://externals.io/message/39291#39307 · In reply to: #39305 Hi, David Soria Parra wrote: > > > […] > > 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 --- ## #39308 — Richard Quadling — 2008-07-25T09:15:11+00:00 URL: https://externals.io/message/39291#39308 · In reply to: #39291 2008/7/25 Gwynne Raskind > 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 < > svn-migration@lists.php.net> 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 ) 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." > > > -- > > > > Hi. I've been a client user of CVS (php) both SVN and git (strangely enough, for the same project - PrototypeJS). As a windows user my observations/opinions are ... 1 - CVS uses a version number for versions of a file and tags when branching is necessary. From what I can tell a group of change to many files are not grouped in any obvious way. TortoiseCVS integrates with the Windows Explorer environment. Command line tools are provided as TortoiseCVS uses them "behind the scenes". I've also got Cygwin's cvs. 2 - SVN uses a version number for versions of a file and uses directories when branching is necessary. Groups of changes are connected via a "changeset". TortoiseSVN integrates with the Windows Explorer environment in a similar method to that of TortoiseCVS. I've also got Cygwin's svn. 3 - GIT uses a SHA1 hash to group the changes. I find this next to useless to compare versions as there is no version number per se (at least not one I can see). I've only got git-gui for Windows. It works very differently to the Tortoise tools. Purely from my own experience and knowledge level, I like SVN. I like the idea of a group of changes being linked. I miss the version numbering (it may just be that Prototype don't need them ...). git feels very different to CSV and SVN. It may just be I need to change the way I see the information provided. If git can provide in-file version numbering (like CVS does), then that would feel more comfortable than the SHA1 hashes used. Richard. -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #39309 — Marcus Boerger — 2008-07-25T09:46:22+00:00 URL: https://externals.io/message/39291#39309 · In reply to: #39303 Hello Lukas, Friday, July 25, 2008, 10:15:08 AM, you 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? 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. marcus Best regards, Marcus --- ## #39310 — Marcus Boerger — 2008-07-25T09:56:15+00:00 URL: https://externals.io/message/39291#39310 · In reply to: #39306 Hello Lukas, Friday, July 25, 2008, 10:26:59 AM, you wrote: > > > […] > 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 --- ## #39311 — Lukas Kahwe Smith — 2008-07-25T09:58:42+00:00 URL: https://externals.io/message/39291#39311 · In reply to: #39309 > > […] > > > […] > > 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 --- ## #39312 — Andrey Hristov — 2008-07-25T10:06:25+00:00 URL: https://externals.io/message/39291#39312 · In reply to: #39307 Oops, Andrey Hristov wrote: > Hi, > David Soria Parra wrote: > > […] > > 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, should be read as : This is how a MySQL-Proxy bzr repo from Launchpad is provided :) > although the main repo is svn. Launchpad registration is free and easy. > > Best, > Andrey > Andrey --- ## #39314 — johannes@schlueters.de — 2008-07-25T10:26:32+00:00 URL: https://externals.io/message/39291#39314 · In reply to: #39305 > > […] > > 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 --- ## #39315 — Hannes Magnusson — 2008-07-25T10:34:18+00:00 URL: https://externals.io/message/39291#39315 · In reply to: #39291 On Fri, Jul 25, 2008 at 04:06, Gwynne Raskind 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 --- ## #39317 — Scott MacVicar — 2008-07-25T10:41:13+00:00 URL: https://externals.io/message/39291#39317 · In reply to: #39311 > > > > > […] > > I have not used any of them enough in practice to really know them > well. > > > […] > > > 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 > > > > > -- > > > Scott --- ## #39318 — Gwynne Raskind — 2008-07-25T10:44:36+00:00 URL: https://externals.io/message/39291#39318 · In reply to: #39315 > > […] > 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- migration@. 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." --- ## #39320 — Lukas Kahwe Smith — 2008-07-25T10:46:37+00:00 URL: https://externals.io/message/39291#39320 · In reply to: #39317 > > > > > […] > > 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 --- ## #39326 — Andi Gutmans — 2008-07-25T16:42:20+00:00 URL: https://externals.io/message/39291#39326 · In reply to: #39320 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 --- ## #39327 — Marcus Boerger — 2008-07-25T16:59:33+00:00 URL: https://externals.io/message/39291#39327 · In reply to: #39311 Hello Lukas, Friday, July 25, 2008, 11:58:42 AM, you wrote: > > > […] > I have not used any of them enough in practice to really know them well. > > […] > 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 --- ## #39328 — Daniel Brown — 2008-07-25T17:20:03+00:00 URL: https://externals.io/message/39291#39328 · In reply to: #39308 On Fri, Jul 25, 2008 at 5:15 AM, Richard Quadling 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." -- 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. --- ## #39337 — Travis Swicegood — 2008-07-25T19:27:02+00:00 URL: https://externals.io/message/39291#39337 · In reply to: #39327 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 --- ## #39353 — Sebastian Deutsch — 2008-07-26T13:59:13+00:00 URL: https://externals.io/message/39291#39353 · In reply to: #39302 Rasmus Lerdorf schrieb: > Lukas Kahwe Smith wrote: > > […] > > 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 --- Next page: https://externals.io/message/39291.md?page=2