Re: [PHP-DEV] DVCS
Hi, I thought it might be interesting for all to read some feedback I got from some questions I made to the Joomla community, specifically, the guys and gals that have been implementing the decoupling of the Joomla framework: the Joomla Platform. They currently still use svn officially but they have been experimenting with both mercurial and git. These are their responses so far: http://groups.google.com/group/joomla-dev-framework/browse_thread/thread/fd3b0151cc215c0e It may bring some insight to what a DVCS could do for the PHP community. Best regards, David On Thu, Apr 28, 2011 at 2:28 AM, Lester Caine les...@lsces.co.uk wrote: dukeofgaming wrote: http://programmers.stackexchange.com/questions/35074/im-a-subversion-geek-why-i-should-consider-or-not-consider-mercurial-or-git-or/35080#35080 So, I don't want to make debate here of wether centralized is better than distributed (because the point is moot), but I think its not a good situation for the community to have a previously open door to DVCSs now closed. Having been battling with various projects that have decided that 'git is good' or 'hg is best' ... I've been trying to live in the new world and failing. That link is looking like a nice CURRENT overview of the situation although things are still changing mainly for the good. My problem until recently was that 'subrepo' management in DVCS has always been playing catchup. Yesterday for the first time I checked out a 'super-project' matching one of the composite builds provided on an original CVS repo! Still not fully integrated into Eclipse, but hopefully even that will come with time. But now I can 'clone' the half dozen different builds and manage them in parallel with both github and bitbucket 'masters'. I'm using Mercurial and TortoiseHg which almost work transparently between Linux and Windows, and with hg-git access to the 'git is good' projects is also transparent even on windows. Next step this weekend IS to tidy up the SVN setup so that I have the PHP code locally mirrored as well -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DVCS
dukeofgaming wrote: I thought it might be interesting for all to read some feedback I got from some questions I made to the Joomla community, specifically, the guys and gals that have been implementing the decoupling of the Joomla framework: the Joomla Platform. They currently still use svn officially but they have been experimenting with both mercurial and git. These are their responses so far: http://groups.google.com/group/joomla-dev-framework/browse_thread/thread/fd3b0151cc215c0e It may bring some insight to what a DVCS could do for the PHP community. I think that there are perhaps still a couple of separate problems here which the DVCS community need to get behind for any of them to become a 'front runner'. The main problem here IS 'subrepo' which is a concept that neither HG or GIT handle particularly well, but to my mind is essential for a very much modular project like PHP! While I have sort of managed to put together a 'checkout' of a set of packages which together make a single build of the target project, I'm still having to pull and commit changes manually to each subrepo - I don't get the simple overview of outstanding changes that was SO nice to work with in CVS! To try and put this in a 'PHP' context ... I DID have a list of extensions I was working with, and a 'sync' in ECLIPSE gave me a nice list of which ones had had changes pushed ... I could then go and either simply update to those changes on an extension by extension basis - or review the changes in each file so allow me to integrate other peoples changes with my own local 'tweaks'. This is something that DVCS SHOULD be perfect for, but the management tools for bundling a selection of parts of a project are not there yet, mainly because the core developers on both HG and GIT don't see then need because they don't need that type of working! I'm limping along with HG at the moment simply because it works on both Linux AND Windows, while GIT's windows support is still rather hit and miss when one is already using other unix tools on windows, but I do not have the same level of integration in Eclipse that CVS and SVN provide beautify straight out of the box. At least I can drop out of Eclipse into TortoiseHg and do the code management, but it's not an ideal way of working. If I was a 'console jockey' then much of this would probably be a lot less of a problem. One seems to need to write scripts to do what YOU want to do in both HG and GIT - and then need to learn Python to do that in HG :( But I never used CVS from the command line so a LOT of the reasoning for even the switch to SVN was irrelevant since Eclipse had already solved all of those 'problems'. At the current time I think that PHP would need to restructure how it is packaged up to provide a single repo in both HG or GIT. Keeping SVN ( I'd still prefer CVS here it works BETTER as a master for DVCS! ) as the master from which we CAN currently sync using HG or GIT is the best of a bad job currently. Unless some knows better? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DVCS
On 1 June 2011 12:41, Lester Caine les...@lsces.co.uk wrote: At the current time I think that PHP would need to restructure how it is packaged up to provide a single repo in both HG or GIT. Keeping SVN ( I'd still prefer CVS here it works BETTER as a master for DVCS! ) as the master from which we CAN currently sync using HG or GIT is the best of a bad job currently. Unless some knows better I know what you mean. There are solutions like submodules in GIT but it does require some small restructuring usually. By the way, TortoiseGIT is now quite excellent for Windows GUI. A new version 1.7.0 is just about to be released too. I'm a bit biased against GIT but overall, GIT is getting way more traction than Hg and github.com excels in features compared to anything else. From what I have seen also, IDE integration with GIT is starting to catchup both in NetBeans and Eclipse - and already way ahead of the pack is phpStorm for VCS integration, but it's not free. Regards, Drak
Re: [PHP-DEV] DVCS
Hi Lester, AFAIK both mercurial and git support sub-repositories nicely now: http://mercurial.selenic.com/wiki/Subrepository http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html Regarding the graphical tools, I don't use them that much, but I see your point. Personally, I just occasionally use the Netbeans integration because it is easier to commit files in separate directories, but that is pretty much it since I think the rest is easier and quicker to do with the console, but I guess it will always be a matter of personal preference. I've been working with hg subrepos and they are quite nice. I'm still not that familiar with git submodules. BTW, you don't need to use python to customize/extend mercurial's behavior, you can use hooks: http://mercurial.selenic.com/wiki/Hook Best regards, David On Wed, Jun 1, 2011 at 1:56 AM, Lester Caine les...@lsces.co.uk wrote: dukeofgaming wrote: I thought it might be interesting for all to read some feedback I got from some questions I made to the Joomla community, specifically, the guys and gals that have been implementing the decoupling of the Joomla framework: the Joomla Platform. They currently still use svn officially but they have been experimenting with both mercurial and git. These are their responses so far: http://groups.google.com/group/joomla-dev-framework/browse_thread/thread/fd3b0151cc215c0e It may bring some insight to what a DVCS could do for the PHP community. I think that there are perhaps still a couple of separate problems here which the DVCS community need to get behind for any of them to become a 'front runner'. The main problem here IS 'subrepo' which is a concept that neither HG or GIT handle particularly well, but to my mind is essential for a very much modular project like PHP! While I have sort of managed to put together a 'checkout' of a set of packages which together make a single build of the target project, I'm still having to pull and commit changes manually to each subrepo - I don't get the simple overview of outstanding changes that was SO nice to work with in CVS! To try and put this in a 'PHP' context ... I DID have a list of extensions I was working with, and a 'sync' in ECLIPSE gave me a nice list of which ones had had changes pushed ... I could then go and either simply update to those changes on an extension by extension basis - or review the changes in each file so allow me to integrate other peoples changes with my own local 'tweaks'. This is something that DVCS SHOULD be perfect for, but the management tools for bundling a selection of parts of a project are not there yet, mainly because the core developers on both HG and GIT don't see then need because they don't need that type of working! I'm limping along with HG at the moment simply because it works on both Linux AND Windows, while GIT's windows support is still rather hit and miss when one is already using other unix tools on windows, but I do not have the same level of integration in Eclipse that CVS and SVN provide beautify straight out of the box. At least I can drop out of Eclipse into TortoiseHg and do the code management, but it's not an ideal way of working. If I was a 'console jockey' then much of this would probably be a lot less of a problem. One seems to need to write scripts to do what YOU want to do in both HG and GIT - and then need to learn Python to do that in HG :( But I never used CVS from the command line so a LOT of the reasoning for even the switch to SVN was irrelevant since Eclipse had already solved all of those 'problems'. At the current time I think that PHP would need to restructure how it is packaged up to provide a single repo in both HG or GIT. Keeping SVN ( I'd still prefer CVS here it works BETTER as a master for DVCS! ) as the master from which we CAN currently sync using HG or GIT is the best of a bad job currently. Unless some knows better? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DVCS
Drak wrote: At the current time I think that PHP would need to restructure how it is packaged up to provide a single repo in both HG or GIT. Keeping SVN ( I'd still prefer CVS here it works BETTER as a master for DVCS! ) as the master from which we CAN currently sync using HG or GIT is the best of a bad job currently. Unless some knows better I know what you mean. There are solutions like submodules in GIT but it does require some small restructuring usually. By the way, TortoiseGIT is now quite excellent for Windows GUI. A new version 1.7.0 is just about to be released too. I'm a bit biased against GIT but overall, GIT is getting way more traction than Hg and github.com http://github.com excels in features compared to anything else. When TortoiseGIT runs in Linux as well - they will have caught up! TortoiseHg works transparently in both and on Mac I believe. My customer base is mainly windows biased while I've been running on Linux here for some years now. I need both platforms to do the same thing - which Eclipse has provided for several years, but the DVCS camps still need to address. Windows GIT is something different from Linux GIT at the moment - which is probably all that is putting me off it. Actually when I was forced to used GIT the windows side simply did not work at all, so I HAD to use hggit to get anything! From what I have seen also, IDE integration with GIT is starting to catchup both in NetBeans and Eclipse - and already way ahead of the pack is phpStorm for VCS integration, but it's not free. hggit + Mercurial Eclipse + Eclipse means I could not care less what the target is EXCEPT that one can't write a project that is JUST the set of sub-modules that you want to pull together. IDEALLY - both GIT and HG would just pull stuff from which ever is providing a particular library? So say Smarty could be on one while ADOdb is on the other ... The core PHP code does not need to be so distributed, but being able to pull PECL modules from a number of sources to add to a core clone of the code could be useful? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DVCS
On Wed, Jun 1, 2011 at 2:37 AM, Lester Caine les...@lsces.co.uk wrote: Drak wrote: At the current time I think that PHP would need to restructure how it is packaged up to provide a single repo in both HG or GIT. Keeping SVN ( I'd still prefer CVS here it works BETTER as a master for DVCS! ) as the master from which we CAN currently sync using HG or GIT is the best of a bad job currently. Unless some knows better I know what you mean. There are solutions like submodules in GIT but it does require some small restructuring usually. By the way, TortoiseGIT is now quite excellent for Windows GUI. A new version 1.7.0 is just about to be released too. I'm a bit biased against GIT but overall, GIT is getting way more traction than Hg and github.com http://github.com excels in features compared to anything else. When TortoiseGIT runs in Linux as well - they will have caught up! TortoiseHg works transparently in both and on Mac I believe. My customer base is mainly windows biased while I've been running on Linux here for some years now. I need both platforms to do the same thing - which Eclipse has provided for several years, but the DVCS camps still need to address. Windows GIT is something different from Linux GIT at the moment - which is probably all that is putting me off it. Actually when I was forced to used GIT the windows side simply did not work at all, so I HAD to use hggit to get anything! From what I have seen also, IDE integration with GIT is starting to catchup both in NetBeans and Eclipse - and already way ahead of the pack is phpStorm for VCS integration, but it's not free. hggit + Mercurial Eclipse + Eclipse means I could not care less what the target is EXCEPT that one can't write a project that is JUST the set of sub-modules that you want to pull together. IDEALLY - both GIT and HG would just pull stuff from which ever is providing a particular library? So say Smarty could be on one while ADOdb is on the other ... The core PHP code does not need to be so distributed, but being able to pull PECL modules from a number of sources to add to a core clone of the code could be useful? Perhaps, it would depend how teams are structured, but even it was a single repository for everything I think stuff would work fine. My opinion is that the reason behind sub-repositories is to include code from vendors, not that much to modularize development of a single big project, why?, because of the distributed nature of a DVCS: imagine that there is a PECL team, and that team makes a fork of the main PHP repository, and they focus on that fork (every separate repository can be regarded as a fork) and they handle all their work integration, and then someone (after an ammount of work is done) pulls back from the main repo (the one where last integrations are agreed to be added, central if you must call it that) to ensure everything still runs ok, and then ask to the final integrator to pull and merge their work: done. Oh, and HG supports svn and git as subrepos now. Regards, David
Re: [PHP-DEV] DVCS
dukeofgaming wrote: I know it will be a while until any choice of DVCS is adopted by PHP, but I'll be creating an RFC as soon as I can edit the wiki (I can edit the rfc namespace but cannot edit the rfc page itself to add the entry) so that we can start making note of the current challenges and choices. http://lsces.co.uk/wiki/index.php?page=DVCS+adoption+notes is getting rather long in the tooth and I need to rework my own implementation notes as a number of things have changed. http://lsces.co.uk/hg/ will have all of my PHP base added soon, but recursion into projects is still a 'todo' here, so http://lsces.co.uk/hg/bitweaver2/ is not linking properly and at some point hopefully it WILL drill down to smarty, adodb, ckeditor, and the javascript libraries ... The principles are fine, the mechanics still need to be completed ... and all of THAT is detracting from writing the PHP code which pays the bills :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DVCS
On Thu, Apr 28, 2011 at 4:10 AM, Ben Schmidt mail_ben_schm...@yahoo.com.auwrote: Hi! I realise that at least for now, PHP is sticking with SVN. No problems. However...I find it much easier to work in Mercurial to put together patches, find bugs, etc.. And in fact, I find SVN really awkward--I was on the verge of switching back to CVS when DVCSes such as Mercurial and Git became popular. I would put in a vote for Mercurial if PHP decides to move to a DVCS. Mercurial is more similar to CVS/SVN in its command set than other DVCSes, is easy and friendly to use, generally does what you would expect, makes it pretty hard to shoot yourself in the foot, and includes good Windows support. Operating with the Mozilla and Vim Mercurial repositories is a lovely experience, and I'd love to add PHP to the list of projects I follow this way. However, pushing the team towards a DVCS is not what I'm writing for. Certainly not to push for a particular one. I'd just like to be able to use my tool of choice (Mercurial) locally. Would it be possible to set up a Mercurial mirror of the SVN repo on, say, bitbucket.org, so I could pull from there? Alternatively, I can access a git repo somewhere like github.com (I found https://github.com/php/php-src but the last activity seems to be about 9 months ago--is it dead? are there any plans to revive it?). Of course, as a last resort, I could just access SVN using Mercurial. However, it may result in a lower server load if PHP can provide a mirror somewhere, updated by a commit hook or daily cron job or something, rather than me (and potentially many others, as DVCSes become even more popular) accessing SVN directly. Any possibility? (I'm happy to help, if I can be given appropriate access to resources to do so.) Ben. anybody out there, who didn't tried github yet, should really do it. and you can use your svn client to interact with your github repo, if you didn't feel the need to learn git. https://github.com/blog/644-subversion-write-support Tyrael
Re: [PHP-DEV] DVCS
dukeofgaming wrote: http://programmers.stackexchange.com/questions/35074/im-a-subversion-geek-why-i-should-consider-or-not-consider-mercurial-or-git-or/35080#35080 So, I don't want to make debate here of wether centralized is better than distributed (because the point is moot), but I think its not a good situation for the community to have a previously open door to DVCSs now closed. Having been battling with various projects that have decided that 'git is good' or 'hg is best' ... I've been trying to live in the new world and failing. That link is looking like a nice CURRENT overview of the situation although things are still changing mainly for the good. My problem until recently was that 'subrepo' management in DVCS has always been playing catchup. Yesterday for the first time I checked out a 'super-project' matching one of the composite builds provided on an original CVS repo! Still not fully integrated into Eclipse, but hopefully even that will come with time. But now I can 'clone' the half dozen different builds and manage them in parallel with both github and bitbucket 'masters'. I'm using Mercurial and TortoiseHg which almost work transparently between Linux and Windows, and with hg-git access to the 'git is good' projects is also transparent even on windows. Next step this weekend IS to tidy up the SVN setup so that I have the PHP code locally mirrored as well -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DVCS
On 04/27/2011 07:10 PM, Ben Schmidt wrote: However, it may result in a lower server load if PHP can provide a mirror somewhere, updated by a commit hook or daily cron job or something, rather than me (and potentially many others, as DVCSes become even more popular) accessing SVN directly. The server load was actually what caused us to turn off the git mirroring. Every time the mirror job ran it slammed the svn server and there weren't enough people using it to warrant that load. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DVCS
On 28 April 2011 07:55, Ben Schmidt mail_ben_schm...@yahoo.com.au wrote: I realise that at least for now, PHP is sticking with SVN. No problems. I realise this is not the topic of discussion but I have to say, that overall, a switch to DVCS would make a huge difference to PHP development life cycles. Git for one, makes contributing and integration of patches a completely different experience. It encourages more community participation without impinging on quality since you don't need to grant commit permissions. The whole workflow of creating and integrating patches is much faster and more simple because you can switch context from branch to branch almost instantly allowing those with commit permissions to verify if a contribution is worth merging or not. It's much less work than SVN and the ease naturally attracts contributors. Merging is not a pita like with SVN. However, given the recent security breach there is another side: Tampering with a git repository is virtually impossible because every commit hash is generated from the previous ones, so if your servers were compromised again, a change in the past history would require alteration every single commit hash since that change and the resulting HEAD hash would be different. Since hashes are based on the commit contents it's just not feasible even if SHA1 was one day compromised that you could successfully tamper with a previous commit and engineer the calculations so the current HEAD hash remained unchanged. If a commit blob (on the file-system) was altered manually, your git repo would simply fail to validate the next time you use it. In every scenario you'd know immediately something was wrong and not have to go looking for it commit by commit. Something to consider again in the future at least. Regards, Drak
Re: [PHP-DEV] DVCS
On 04/27/2011 07:40 PM, Drak wrote: On 28 April 2011 07:55, Ben Schmidtmail_ben_schm...@yahoo.com.au wrote: I realise that at least for now, PHP is sticking with SVN. No problems. I realise this is not the topic of discussion but I have to say, that overall, a switch to DVCS would make a huge difference to PHP development life cycles. Git for one, makes contributing and integration of patches a completely different experience. It encourages more community participation without impinging on quality since you don't need to grant commit permissions. The whole workflow of creating and integrating patches is much faster and more simple because you can switch context from branch to branch almost instantly allowing those with commit permissions to verify if a contribution is worth merging or not. It's much less work than SVN and the ease naturally attracts contributors. Merging is not a pita like with SVN. However, given the recent security breach there is another side: Tampering with a git repository is virtually impossible because every commit hash is generated from the previous ones, so if your servers were compromised again, a change in the past history would require alteration every single commit hash since that change and the resulting HEAD hash would be different. Since hashes are based on the commit contents it's just not feasible even if SHA1 was one day compromised that you could successfully tamper with a previous commit and engineer the calculations so the current HEAD hash remained unchanged. If a commit blob (on the file-system) was altered manually, your git repo would simply fail to validate the next time you use it. In every scenario you'd know immediately something was wrong and not have to go looking for it commit by commit. Something to consider again in the future at least. Verifying the svn repository was the least painful part of that experience. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DVCS
Hi, I'm not a frequent poster in the list but I thought I'd really should give my 1 cent here when I saw popular being an argument for using DVCSs, its not, and its neither fashion nor cargo cult, it is just a plain eye opener experience of how neither SVN or CVS are the base of all versioning (two of its creators —Brian Fitzpatrick and Ben Collins-Sussman— have acknowledged this by saying sorry about that with regards to Subversion) and that better and more natural ways to collaborate and integrate code. I could provide an epically long argument here, but instead I'll link to the one I've already made, diagrams and graphics included =): http://programmers.stackexchange.com/questions/35074/im-a-subversion-geek-why-i-should-consider-or-not-consider-mercurial-or-git-or/35080#35080 So, I don't want to make debate here of wether centralized is better than distributed (because the point is moot), but I think its not a good situation for the community to have a previously open door to DVCSs now closed. Perhaps a solution can be found to even open the door to Mercurial (that is an excellent place to start with DVCSs because its simplicity and straight-forwardness) in addition to git in such a way that doesn't stress the server?. Regards, David On Wed, Apr 27, 2011 at 9:40 PM, Drak d...@zikula.org wrote: On 28 April 2011 07:55, Ben Schmidt mail_ben_schm...@yahoo.com.au wrote: I realise that at least for now, PHP is sticking with SVN. No problems. I realise this is not the topic of discussion but I have to say, that overall, a switch to DVCS would make a huge difference to PHP development life cycles. Git for one, makes contributing and integration of patches a completely different experience. It encourages more community participation without impinging on quality since you don't need to grant commit permissions. The whole workflow of creating and integrating patches is much faster and more simple because you can switch context from branch to branch almost instantly allowing those with commit permissions to verify if a contribution is worth merging or not. It's much less work than SVN and the ease naturally attracts contributors. Merging is not a pita like with SVN. However, given the recent security breach there is another side: Tampering with a git repository is virtually impossible because every commit hash is generated from the previous ones, so if your servers were compromised again, a change in the past history would require alteration every single commit hash since that change and the resulting HEAD hash would be different. Since hashes are based on the commit contents it's just not feasible even if SHA1 was one day compromised that you could successfully tamper with a previous commit and engineer the calculations so the current HEAD hash remained unchanged. If a commit blob (on the file-system) was altered manually, your git repo would simply fail to validate the next time you use it. In every scenario you'd know immediately something was wrong and not have to go looking for it commit by commit. Something to consider again in the future at least. Regards, Drak
Re: [PHP-DEV] DVCS
On 28 April 2011 08:52, dukeofgaming dukeofgam...@gmail.com wrote: Hi, I'm not a frequent poster in the list but I thought I'd really should give my 1 cent here when I saw popular being an argument for using DVCSs, its not, and its neither fashion nor cargo cult, it is just a plain eye opener experience of how neither SVN or CVS are the base of all versioning (two of its creators —Brian Fitzpatrick and Ben Collins-Sussman— have acknowledged this by saying sorry about that with regards to Subversion) and that better and more natural ways to collaborate and integrate code. I could provide an epically long argument here, but instead I'll link to the one I've already made, diagrams and graphics included =): http://programmers.stackexchange.com/questions/35074/im-a-subversion-geek-why-i-should-consider-or-not-consider-mercurial-or-git-or/35080#35080 So, I don't want to make debate here of wether centralized is better than distributed (because the point is moot), but I think its not a good situation for the community to have a previously open door to DVCSs now closed. Perhaps a solution can be found to even open the door to Mercurial (that is an excellent place to start with DVCSs because its simplicity and straight-forwardness) in addition to git in such a way that doesn't stress the server?. For us, there was huge reluctance in our community to move away from SVN and we solved all our differenced with a GIT/SVN bridge. I personally wanted to use GIT so I just checked out our SVN tree using GIT-SVN. Meant I could use all the features of GIT locally and when I needed to svn update/svn commit, GIT does that part invisibly. I am sure there are things like this for Mercurial etc. For windows: TortoiseGIT (has SVN support built in). Debian/Ubuntu: apt-get install git-core git-svn As much as purist for DVCS balk at the SVN bridges, I think they are an important stepping stone for people who are used to SVN. It allows one to try it out on the project the know and love without forcing the project to switch. That's the better way. For those who would prefer GIT or whatever but their project prefers SVN, the bridge allows them to use it without upsetting the project status quo. They really work well too: locally you can branch and merge and do all the gymnastics you cant achieve with SVN. Overall, I think it's only recently that DVCS tools are becoming matured. I know even a year ago GIT's toolset was horrific, but there have been recent leaps an bounds in the toolsets and services like github.com have made the entire experience very easy and social. My main point is, if you want to use DVCS, there is nothing stopping you doing right now, without asking the PHP team to change the VCS (although I would hope one day they do). Regards, Drak
Re: [PHP-DEV] DVCS
Hi Ben, I'm sorry I did a wrong remark there, but I see you saw what I meant. The nice thing about open source projects is that communities develop naturally around them, it becomes an ecosystem, everything tends to lean towards balance, when a change is intended to be made it should be allowed to develop organically. Point here is: lets not try to force DVCSs but rather keep the door open so the community can pass through it whenever it feels ready, so the dilema of current devs vs potential devs never happens. My advice here is —if current devs are willing— to pilot test a DVCS on a small part of the project where it can be used primarily (as in not with subversion); this would be a very healthy exercise to understand the why of this generalized DVCS-ish concern. Another advice is to open the discussion towards the choice of a DVCS in comparison to the project's interests and demographics (e.g. if there are more windows users than mac/linux, mercurial would be preferred, if its the other way around there is an underlying git community, git might be best). To all who doubt DVCS, this is a good read for you: http://hginit.com/00.html In relation to Drak's remarks, yes, I think the maturity of the tools has contributed to its increased usage, and also, the very cool services around them, such as github.com and bitbucket.org. Finally, I think from here on, the conversation should be focused on finding a technical solution to the load problem (I'm not familiar with the setup, but if I think of something I'll post it). Regards, David On Wed, Apr 27, 2011 at 10:29 PM, Ben Schmidt mail_ben_schm...@yahoo.com.au wrote: Just for the recordI didn't say popularity was a reason to use a DVCS. I said the popularity of DVCSes might cause server strain (if a lot of people want to convert the public SVN repo to a distributed one, downloading all the changes in the repo, which SVN really wasn't designed for, that would be a heavy load--and positively correlated to popularity: more popular, more conversions, more load). I agree with your closing point, though: I'd love to see us look for a low-load way of providing an Hg mirror and/or a Git mirror. I also think that either a mirror or a change of VCS may attract developers in the medium-term. However, I also think that current developers carry a lot more weight than potential developers, and it's important for them to be able to work in a way that is comfortable for them. So a mirror or two would be nice, and I'd push for that, but a change of official repo I will merely suggest be considered longer term. Ben. On 28/04/11 1:07 PM, dukeofgaming wrote: Hi, I'm not a frequent poster in the list but I thought I'd really should give my 1 cent here when I saw popular being an argument for using DVCSs, its not, and its neither fashion nor cargo cult, it is just a plain eye opener experience of how neither SVN or CVS are the base of all versioning (two of its creators —Brian Fitzpatrick and Ben Collins-Sussman— have acknowledged this by saying sorry about that with regards to Subversion) and that better and more natural ways to collaborate and integrate code. I could provide an epically long argument here, but instead I'll link to the one I've already made, diagrams and graphics included =): http://programmers.stackexchange.com/questions/35074/im-a-subversion-geek-why-i-should-consider-or-not-consider-mercurial-or-git-or/35080#35080 So, I don't want to make debate here of wether centralized is better than distributed (because the point is moot), but I think its not a good situation for the community to have a previously open door to DVCSs now closed. Perhaps a solution can be found to even open the door to Mercurial (that is an excellent place to start with DVCSs because its simplicity and straight-forwardness) in addition to git in such a way that doesn't stress the server?. Regards, David On Wed, Apr 27, 2011 at 9:40 PM, Drakd...@zikula.org wrote: On 28 April 2011 07:55, Ben Schmidtmail_ben_schm...@yahoo.com.au wrote: I realise that at least for now, PHP is sticking with SVN. No problems. I realise this is not the topic of discussion but I have to say, that overall, a switch to DVCS would make a huge difference to PHP development life cycles. Git for one, makes contributing and integration of patches a completely different experience. It encourages more community participation without impinging on quality since you don't need to grant commit permissions. The whole workflow of creating and integrating patches is much faster and more simple because you can switch context from branch to branch almost instantly allowing those with commit permissions to verify if a contribution is worth merging or not. It's much less work than SVN and the ease naturally attracts contributors. Merging is not a pita like with SVN. However, given the recent security breach there is another side:
Re: [PHP-DEV] DVCS
I think I agree with all that. My only thought so far about the load issue is that the load is less the fewer changesets have to be queried each 'poll', so perhaps it would be good to have a commit hook in SVN that sends a quick request (without even waiting for a reply) to Hg/Git scripts that just notifies them that they should poll. There is no polling at fixed intervals then (e.g. daily, where a lot of commits need to be picked up at once, or every few minutes which might often find no commits and be a waste of resources), but neither does it create a bottleneck (SVN commits don't have to wait for mirrors to be updated before succeeding). Mirroring could just kick in a few seconds after each commit and pick it up. Another possibility, and actually I think this is a good one, is to mirror to just Hg or Git, and then use Hg-git (a Mercurial extension) to mirror one from the other. Then only one mirror needs to interact with SVN, so the load is less, but we support both major DVCSes. The particularly nice thing about Hg-git is that it does changeset conversion losslessly, so if this is used, people using Hg and Git can collaborate, too. Conversion to/from SVN isn't lossless unfortunately. :-) (For now, I'm just using hgsubversion to get SVN into a local Hg repo, but will change to use an official mirror basically immediately if we can create one, in order to help reduce the load.) Ben. On 28/04/11 2:30 PM, dukeofgaming wrote: Hi Ben, I'm sorry I did a wrong remark there, but I see you saw what I meant. The nice thing about open source projects is that communities develop naturally around them, it becomes an ecosystem, everything tends to lean towards balance, when a change is intended to be made it should be allowed to develop organically. Point here is: lets not try to force DVCSs but rather keep the door open so the community can pass through it whenever it feels ready, so the dilema of current devs vs potential devs never happens. My advice here is —if current devs are willing— to pilot test a DVCS on a small part of the project where it can be used primarily (as in not with subversion); this would be a very healthy exercise to understand the why of this generalized DVCS-ish concern. Another advice is to open the discussion towards the choice of a DVCS in comparison to the project's interests and demographics (e.g. if there are more windows users than mac/linux, mercurial would be preferred, if its the other way around there is an underlying git community, git might be best). To all who doubt DVCS, this is a good read for you: http://hginit.com/00.html In relation to Drak's remarks, yes, I think the maturity of the tools has contributed to its increased usage, and also, the very cool services around them, such as github.com and bitbucket.org. Finally, I think from here on, the conversation should be focused on finding a technical solution to the load problem (I'm not familiar with the setup, but if I think of something I'll post it). Regards, David On Wed, Apr 27, 2011 at 10:29 PM, Ben Schmidtmail_ben_schm...@yahoo.com.au wrote: Just for the recordI didn't say popularity was a reason to use a DVCS. I said the popularity of DVCSes might cause server strain (if a lot of people want to convert the public SVN repo to a distributed one, downloading all the changes in the repo, which SVN really wasn't designed for, that would be a heavy load--and positively correlated to popularity: more popular, more conversions, more load). I agree with your closing point, though: I'd love to see us look for a low-load way of providing an Hg mirror and/or a Git mirror. I also think that either a mirror or a change of VCS may attract developers in the medium-term. However, I also think that current developers carry a lot more weight than potential developers, and it's important for them to be able to work in a way that is comfortable for them. So a mirror or two would be nice, and I'd push for that, but a change of official repo I will merely suggest be considered longer term. Ben. On 28/04/11 1:07 PM, dukeofgaming wrote: Hi, I'm not a frequent poster in the list but I thought I'd really should give my 1 cent here when I saw popular being an argument for using DVCSs, its not, and its neither fashion nor cargo cult, it is just a plain eye opener experience of how neither SVN or CVS are the base of all versioning (two of its creators —Brian Fitzpatrick and Ben Collins-Sussman— have acknowledged this by saying sorry about that with regards to Subversion) and that better and more natural ways to collaborate and integrate code. I could provide an epically long argument here, but instead I'll link to the one I've already made, diagrams and graphics included =): http://programmers.stackexchange.com/questions/35074/im-a-subversion-geek-why-i-should-consider-or-not-consider-mercurial-or-git-or/35080#35080 So, I don't want to make debate here of wether centralized is better
