Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
On 26 August 2011 08:48, dukeofgaming dukeofgam...@gmail.com wrote: Having current SVN-only contributors learn it might going to be quite a challenge. That's me. And I am VERY used to TortoiseSVN - a visual tool integrated into Windows Explorer (not IE, but the filesystem exploring tool for Windows). I recently worked with some mac users and they were a little jealous of that ability. I point and click and commit from my explorer. I really don't want to have to work at the command line. Sure I can, but the tool needs to be a LOT easier than that. With SVN, things feel pretty simple. I don't currently get git. It SEEMS very complicated for no gain - when all I'm working on is 1 extension (pecl/win32service) and phpdoc. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
there is the same for git. Even most IDEs have plugin for git support these days. Lack of GUI is definitively not an argument. On Sat, Aug 27, 2011 at 12:47 PM, Richard Quadling rquadl...@gmail.com wrote: On 26 August 2011 08:48, dukeofgaming dukeofgam...@gmail.com wrote: Having current SVN-only contributors learn it might going to be quite a challenge. That's me. And I am VERY used to TortoiseSVN - a visual tool integrated into Windows Explorer (not IE, but the filesystem exploring tool for Windows). I recently worked with some mac users and they were a little jealous of that ability. I point and click and commit from my explorer. I really don't want to have to work at the command line. Sure I can, but the tool needs to be a LOT easier than that. With SVN, things feel pretty simple. I don't currently get git. It SEEMS very complicated for no gain - when all I'm working on is 1 extension (pecl/win32service) and phpdoc. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
On Sat, Aug 27, 2011 at 12:47 PM, Richard Quadling rquadl...@gmail.com wrote: On 26 August 2011 08:48, dukeofgaming dukeofgam...@gmail.com wrote: Having current SVN-only contributors learn it might going to be quite a challenge. That's me. And I am VERY used to TortoiseSVN - a visual tool integrated into Windows Explorer (not IE, but the filesystem exploring tool for Windows). I recently worked with some mac users and they were a little jealous of that ability. I point and click and commit from my explorer. I really don't want to have to work at the command line. Sure I can, but the tool needs to be a LOT easier than that. With SVN, things feel pretty simple. I don't currently get git. It SEEMS very complicated for no gain - when all I'm working on is 1 extension (pecl/win32service) and phpdoc. you should check out tortoisegit then. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
Richard Quadling wrote: Having current SVN-only contributors learn it might going to be quite a challenge. That's me. And I am VERY used to TortoiseSVN - a visual tool integrated into Windows Explorer (not IE, but the filesystem exploring tool for Windows). I really don't want to have to work at the command line. Sure I can, but the tool needs to be a LOT easier than that. I use CVS and SVN directly from Eclipse and I know exactly where you are coming from. Currently this all runs transparently on all platforms and many of the 'reasons' given for wanting to change are already supported by additional tools _in_ Eclipse. Up until recently DVCS systems did not have such will integrated support, and this was the cause of most of my own problems. Having machines running both Windows and Linux in parallel for testing purposes I certainly don't want to be having to think which platform I am on and changing the help manual! TortoiseHg provides an independent integrated GUI which I currently use in parallel with Eclipse to support Hg and git via hggit, but it lacks some of the nice features of the SVN integration. MercurialEclipse has made a lot of progress in the last few months and is starting to mimic the SVN tools, but still has a few rough edges. Certainly it's developers are targeted at making that better. The Git GUI support is considerably more disjointed. Nothing is available that works transparently cross platform! The EGit plugin for Eclipse still does not support submodules and is rather basic in it's other functions, but now that I have my Eclipse/TortoiseHg setup working something like stably, I am actually _almost_ back to the same functionality that I've had on CVS and SVN repo's for many years, and on the whole can just access github and gitorious via that. The jump to git by many projects had nothing to do with improving functionality and everything to do with jumping on 'this is the new sourceforge' bandwagon. The majority of the world uses Windows - it does not mean it's the right answer to the problem ;) -- 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] [VOTE] Choosing a distributed version control system for PHP
Lester Caine les...@lsces.co.uk writes: Richard Quadling wrote: Having current SVN-only contributors learn it might going to be quite a challenge. That's me. And I am VERY used to TortoiseSVN - a visual tool integrated into Windows Explorer (not IE, but the filesystem exploring tool for Windows). I really don't want to have to work at the command line. Sure I can, but the tool needs to be a LOT easier than that. I use CVS and SVN directly from Eclipse and I know exactly where you are coming from. Currently this all runs transparently on all platforms and many of the reasons' given for wanting to change are already supported by additional tools _in_ Eclipse. Up until recently DVCS systems did not have such will integrated support, and this was the cause of most of my own problems. Having machines running both Windows and Linux in parallel for testing purposes I certainly don't want to be having to think which platform I am on and changing the help manual! Why would you need to change any manuals? You follow a procedure and the user decides which client he wishes to perform those procedures and to interface to the chosen vcs. TortoiseHg provides an independent integrated GUI which I currently use in parallel with Eclipse to support Hg and git via hggit, but it lacks some of the nice features of the SVN integration. MercurialEclipse has made a lot of progress in the last few months and is starting to mimic the SVN tools, but still has a few rough edges. Certainly it's developers are targeted at making that better. The Git GUI support is considerably more disjointed. Nothing is available that works transparently cross platform! The EGit plugin for Eclipse still does not gitk does for a start. or? support submodules and is rather basic in it's other functions, but now that I have my Eclipse/TortoiseHg setup working something like stably, I am actually _almost_ back to the same functionality that I've had on CVS and SVN repo's for many years, and on the whole can just access github and gitorious via that. The jump to git by many projects had nothing to do with improving functionality and everything to do with jumping on 'this is the new sourceforge' bandwagon. The majority of the world uses Windows - it does not mean it's the right answer to the problem ;) The jump to git was nothing to do with a bandwagon. Its to do with the fact its fast, practical, well supported and efficient and supports distributed development as a core feature. To ignore it in favour of some klunky established system like the god awful svn would be to miss an opportunity to move to what has rapidly become the defacto vcs for many many people. Arguing that the gui ui is a little unwieldy is silly : it will improve and there are other utilities to handle it. git works better than any other vcs I have used : it is in active development and is gaining ground for a reason. As for working transparently cross platform .. How often do you move regularly between a windows machine and a linux mahine for desktop development? There are oodles of things that are not the same - one tiny issue with the *desktop* integration to git will not kill anyone - and besides, editors like emacs hide the OS anyway using something like the wonderful magit. The huge majority of development is done on your local branch anyway. I guess all I am saying is dont dismiss it because you think its too hard to use a slightly different GUI interface or that other people only adopted it because of vogue. People adopted it because it works and works efficiently and well. For those that really really dont know about git, listen to Linux himself:- http://www.youtube.com/watch?v=4XpnKHJAok8 and/or monitor the #git Freenode irc channel. Its popularity is nothing whatsoever to do with a bandwagon. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
I use CVS and SVN directly from Eclipse and I know exactly where you are coming from. Currently this all runs transparently on all platforms and many of the 'reasons' given for wanting to change are already supported by additional tools _in_ Eclipse. http://eclipse.org/egit/ http://www.javaforge.com/project/HGE http://wiki.bazaar.canonical.com/BzrEclipse using the vcs from your IDE, or outside(either via gui or command line) is a personal preference, for example I had problems with the SVN intergration in Eclipse, so I tend to use it outside of Eclipse. At least before I ditched eclipse. Up until recently DVCS systems did not have such will integrated support, and this was the cause of most of my own problems. this has nothing to do with DVCS, usually new tools lacks support from the third parties at first. Having machines running both Windows and Linux in parallel for testing purposes I certainly don't want to be having to think which platform I am on and changing the help manual! you don't necessarily need to edit the code on the different platforms, only build and run it, but having a platform independent development environment is a good thing. TortoiseHg provides an independent integrated GUI which I currently use in parallel with Eclipse to support Hg and git via hggit, but it lacks some of the nice features of the SVN integration. MercurialEclipse has made a lot of progress in the last few months and is starting to mimic the SVN tools, but still has a few rough edges. Certainly it's developers are targeted at making that better. tortoisehg (and tortoisegit) are windows only afaik, so if cross platform compatibility is important to you, I can't see how can you use those. The Git GUI support is considerably more disjointed. Nothing is available that works transparently cross platform! The EGit plugin for Eclipse still does not support submodules and is rather basic in it's other functions, but now that I have my Eclipse/TortoiseHg setup working something like stably, I am actually _almost_ back to the same functionality that I've had on CVS and SVN repo's for many years, and on the whole can just access github and gitorious via that. yeah, the git submodule support for IDEs sucks: https://bugs.eclipse.org/bugs/show_bug.cgi?id=314853 http://code.google.com/p/nbgit/issues/detail?id=38 (Netbeans) http://youtrack.jetbrains.net/issue/IDEA-64024 and the fact that the minority of the git users prefer the command line over the guis doesn't help the issue. :/ The jump to git by many projects had nothing to do with improving functionality and everything to do with jumping on 'this is the new sourceforge' bandwagon. The majority of the world uses Windows - it does not mean it's the right answer to the problem ;) didn't occurred to you that maybe the developers behind those project take those concerns into account, and they chose git because it was worth it? if you think that for your own projects SVN or even CVS is better choice, then use those! but for the php project, we have to find the best possible solution suited for those who will be actually using the version control. our current problems with svn are pretty much laid out in the rfc https://wiki.php.net/rfc/dvcs I would add the fact that our current repo is pretty large(both in data size and in history), so on a few occasions when I tried to merge, or reverse merge, that was surprisingly slow. Another thing which is not explicitly explained just implied: having the ability to commint on your local clone also means that we could keep the blessed repository more clean. here is an example: http://news.php.net/php.pecl.cvs/16388 currently we have to keep patches around for contribution, with dvcs, we could make the collaboration more fluent. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
There are several decent GUI's for git on the Mac side of things; Github has even released their own guy. http://www.git-tower.com/ http://mac.github.com/ http://gitx.frim.nl/ Git tower can be quirky, but you get used to it and the quirks make sense. I haven't really heard much about mac github. And the last I've heard mixed about. But I agree with the previous responders lack of gui support is not a reason. On Sat, Aug 27, 2011 at 10:33 AM, Ferenc Kovacs tyr...@gmail.com wrote: I use CVS and SVN directly from Eclipse and I know exactly where you are coming from. Currently this all runs transparently on all platforms and many of the 'reasons' given for wanting to change are already supported by additional tools _in_ Eclipse. http://eclipse.org/egit/ http://www.javaforge.com/project/HGE http://wiki.bazaar.canonical.com/BzrEclipse using the vcs from your IDE, or outside(either via gui or command line) is a personal preference, for example I had problems with the SVN intergration in Eclipse, so I tend to use it outside of Eclipse. At least before I ditched eclipse. Up until recently DVCS systems did not have such will integrated support, and this was the cause of most of my own problems. this has nothing to do with DVCS, usually new tools lacks support from the third parties at first. Having machines running both Windows and Linux in parallel for testing purposes I certainly don't want to be having to think which platform I am on and changing the help manual! you don't necessarily need to edit the code on the different platforms, only build and run it, but having a platform independent development environment is a good thing. TortoiseHg provides an independent integrated GUI which I currently use in parallel with Eclipse to support Hg and git via hggit, but it lacks some of the nice features of the SVN integration. MercurialEclipse has made a lot of progress in the last few months and is starting to mimic the SVN tools, but still has a few rough edges. Certainly it's developers are targeted at making that better. tortoisehg (and tortoisegit) are windows only afaik, so if cross platform compatibility is important to you, I can't see how can you use those. The Git GUI support is considerably more disjointed. Nothing is available that works transparently cross platform! The EGit plugin for Eclipse still does not support submodules and is rather basic in it's other functions, but now that I have my Eclipse/TortoiseHg setup working something like stably, I am actually _almost_ back to the same functionality that I've had on CVS and SVN repo's for many years, and on the whole can just access github and gitorious via that. yeah, the git submodule support for IDEs sucks: https://bugs.eclipse.org/bugs/show_bug.cgi?id=314853 http://code.google.com/p/nbgit/issues/detail?id=38 (Netbeans) http://youtrack.jetbrains.net/issue/IDEA-64024 and the fact that the minority of the git users prefer the command line over the guis doesn't help the issue. :/ The jump to git by many projects had nothing to do with improving functionality and everything to do with jumping on 'this is the new sourceforge' bandwagon. The majority of the world uses Windows - it does not mean it's the right answer to the problem ;) didn't occurred to you that maybe the developers behind those project take those concerns into account, and they chose git because it was worth it? if you think that for your own projects SVN or even CVS is better choice, then use those! but for the php project, we have to find the best possible solution suited for those who will be actually using the version control. our current problems with svn are pretty much laid out in the rfc https://wiki.php.net/rfc/dvcs I would add the fact that our current repo is pretty large(both in data size and in history), so on a few occasions when I tried to merge, or reverse merge, that was surprisingly slow. Another thing which is not explicitly explained just implied: having the ability to commint on your local clone also means that we could keep the blessed repository more clean. here is an example: http://news.php.net/php.pecl.cvs/16388 currently we have to keep patches around for contribution, with dvcs, we could make the collaboration more fluent. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
See inline. Kiall Sent from a mobile - sorry for being short! On Aug 27, 2011 5:22 p.m., Lester Caine les...@lsces.co.uk wrote: Richard Quadling wrote: Having current SVN-only contributors learn it might going to be quite a challenge. That's me. And I am VERY used to TortoiseSVN - a visual tool integrated into Windows Explorer (not IE, but the filesystem exploring tool for Windows). I really don't want to have to work at the command line. Sure I can, but the tool needs to be a LOT easier than that. I use CVS and SVN directly from Eclipse and I know exactly where you are coming from. Currently this all runs transparently on all platforms and many of the 'reasons' given for wanting to change are already supported by additional tools _in_ Eclipse. Up until recently DVCS systems did not have such will integrated support, and this was the cause of most of my own problems. Having machines running both Windows and Linux in parallel for testing purposes I certainly don't want to be having to think which platform I am on and changing the help manual! Supported by tools in eclipse - to the vast majority of people, this is useless. I would bet no single IDE / text editor has over 10% share of those involved with PHP. Choosing your SCM based on a single IDE 'doing it all' is not a smart move! Ever. TortoiseHg provides an independent integrated GUI which I currently use in parallel with Eclipse to support Hg and git via hggit, but it lacks some of the nice features of the SVN integration. MercurialEclipse has made a lot of progress in the last few months and is starting to mimic the SVN tools, but still has a few rough edges. Certainly it's developers are targeted at making that better. To be honest, this (to me) sounds like you're chasing a dream of one tool to rule them all. You're negative against TortoiseHg is that it doesn't do SVN nicely?!?! What's wrong with using the right tool for the job? Native CLI, or one of the GUIs.. eg TortoiseHg for HG, TortoiseGit for Git and TortoiseSVN for SVN. The Git GUI support is considerably more disjointed. Nothing is available that works transparently cross platform! The EGit plugin for Eclipse still does not support submodules and is rather basic in it's other functions, but now that I have my Eclipse/TortoiseHg setup working something like stably, I am actually _almost_ back to the same functionality that I've had on CVS and SVN repo's for many years, and on the whole can just access github and gitorious via that. I'm betting you could have been back to the same, or higher, productivity levels a long time ago -- if you hadn't been fighting to make the new DVCS look at feel like your old VCS ;) Anyway - Re GUIs I've only ever used TortoiseGit, and even than only when I'm doing windows dev, but it works perfectly. Submodules included. (That is - unless you try and use it to connect to Hg or TFS or well... anything other than git!). And ignoring the current state of play - the GUIs will continue to mature over time. The jump to git by many projects had nothing to do with improving functionality and everything to do with jumping on 'this is the new sourceforge' bandwagon. The majority of the world uses Windows - it does not mean it's the right answer to the problem ;) If Hg was as significantly better than git as you've been portraying, surely people would be jumping by the thousand onto the Hg bandwagon?
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
Ferenc Kovacs wrote: I use CVS and SVN directly from Eclipse and I know exactly where you are coming from. Currently this all runs transparently on all platforms and many of the 'reasons' given for wanting to change are already supported by additional tools _in_ Eclipse. http://eclipse.org/egit/ http://www.javaforge.com/project/HGE http://wiki.bazaar.canonical.com/BzrEclipse None of them yet support some of the code management and merging tools like BeyondCompare inside Eclipse, but even that is coming along nicely. using the vcs from your IDE, or outside(either via gui or command line) is a personal preference, for example I had problems with the SVN intergration in Eclipse, so I tend to use it outside of Eclipse. At least before I ditched eclipse. I know that there are problems with Eclipse, but I've never hit them myself, and all of my PHP code goes through phpeclipse, as does the majority of rest of my code editing on every other language. Off topic - I'd be interested to know what your problems were? I've used BeyondCompare since long before starting to use Eclipse, and that still works better for me than some of the other options in Eclipse. Up until recently DVCS systems did not have such will integrated support, and this was the cause of most of my own problems. this has nothing to do with DVCS, usually new tools lacks support from the third parties at first. Then can we at least hold fire until some of the more glaring problems are fixed - such as egit not supporting submodules ... Having machines running both Windows and Linux in parallel for testing purposes I certainly don't want to be having to think which platform I am on and changing the help manual! you don't necessarily need to edit the code on the different platforms, only build and run it, but having a platform independent development environment is a good thing. So you have never had problems appearing in one platform that are not present in the other? I clone from a single master on a Linux box, but even the working machines are now managed from clones of my master repo base. Since I could not even run the same command line stuff in windows and linux git a year ago, a lot of time was wasted that would have been better spent developing ... Not much of my C code is developed cross platform, but everything else simply has to work on both, and why would I use different methods for some things - which was the point about the 'help manual' I do the same thing at the moment, but there is no way to do that with a git base. TortoiseHg provides an independent integrated GUI which I currently use in parallel with Eclipse to support Hg and git via hggit, but it lacks some of the nice features of the SVN integration. MercurialEclipse has made a lot of progress in the last few months and is starting to mimic the SVN tools, but still has a few rough edges. Certainly it's developers are targeted at making that better. tortoisehg (and tortoisegit) are windows only afaik, so if cross platform compatibility is important to you, I can't see how can you use those. Look closer TortoiseHg is very much cross platform and works as well with Nautilus as it does with Windows Explorer ... and is even packaged with a number of Linux distributions. It is specifically designed to work the same on both! And with hggit hooked up it handles github - as long as the repo is simply too big - such as libreoffice - or has too complex a submodule structure. The Git GUI support is considerably more disjointed. Nothing is available that works transparently cross platform! The EGit plugin for Eclipse still does not support submodules and is rather basic in it's other functions, but now that I have my Eclipse/TortoiseHg setup working something like stably, I am actually _almost_ back to the same functionality that I've had on CVS and SVN repo's for many years, and on the whole can just access github and gitorious via that. yeah, the git submodule support for IDEs sucks: https://bugs.eclipse.org/bugs/show_bug.cgi?id=314853 http://code.google.com/p/nbgit/issues/detail?id=38 (Netbeans) http://youtrack.jetbrains.net/issue/IDEA-64024 and the fact that the minority of the git users prefer the command line over the guis doesn't help the issue. :/ And the original project that I was trying to handle is some 200 submodules. I ended up writing scripts to clone the set I needed for each target - and _still_ have to manually commit each module to github. The jump to git by many projects had nothing to do with improving functionality and everything to do with jumping on 'this is the new sourceforge' bandwagon. The majority of the world uses Windows - it does not mean it's the right answer to the problem ;) didn't occurred to you that maybe the developers behind those project take those concerns into account, and they chose git because it was worth it? If it worked then it might be - but for a large number of development
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
David Muir wrote: FWIW, PEAR is already moving to GitHub. So who dictated that There should at least be a little consistency in PHP and this is just another example of everybody just doing what they want and sod the rest of us :( -- 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] [VOTE] Choosing a distributed version control system for PHP
On Fri, Aug 26, 2011 at 8:48 AM, Lester Caine les...@lsces.co.uk wrote: David Muir wrote: FWIW, PEAR is already moving to GitHub. So who dictated that There should at least be a little consistency in PHP and this is just another example of everybody just doing what they want and sod the rest of us :( the pear group decided that obviously. btw. I thought that only the pear2 infrastructure (site, packages) are moving to github. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
The only think that worries me is that most of the time people choose the service and not the tool. On one hand you have Mercurial, a more than capable DVCS with the lowest barrier of entry IMHO (you will love it while you learn it), and the very good service that is Bitbucket, now kind of catching up to github (but not there yet). However, Bitbucket doesn't have —AFAIK— the quantity of users github has, and that would be extremely healthy for the project. On the other hand you have git, which is a very popular and powerful DVCS, however (you will pull your hairs out while learning it but will love it in the end) it is not as straight-forward to get working as Mercurial. Having current SVN-only contributors learn it might going to be quite a challenge. If I could vote I'd vote for mercurial, but then again, I bet having PHP on github will increase contributions very quickly. Damn. On Fri, Aug 26, 2011 at 1:48 AM, Lester Caine les...@lsces.co.uk wrote: David Muir wrote: FWIW, PEAR is already moving to GitHub. So who dictated that There should at least be a little consistency in PHP and this is just another example of everybody just doing what they want and sod the rest of us :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=**contacthttp://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.phphttp://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
If I could vote I'd vote for mercurial, but then again, I bet having PHP on github will increase contributions very quickly. which is pointless if we can't easily accept/merge the pull requests from the github clone. :/ git itself is a powerful tool, but as AFAIK most of the people in this thread only prefer it over git if we also can use the github. maybe it would be a good idea to split up the dvcs migration to smaller steps (so different part of the current svn repo could be discussed/voted separately), and I also think, that it would be a good idea to create a poll for the current developers: - which vcs are you familiar with - which vcs would you prefer to use for your current work on the php project -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
Ferenc Kovacs wrote: which is pointless if we can't easily accept/merge the pull requests from the github clone. :/ You can very easily accept pull requests from GitHub even if you're not working on GitHub. e.g. I've been working on my own PHP fork, and have submitted a pull request to the PHP project. My repo is at https://github.com/rmccue/my-php-fork in the master branch. $ git remote add github-rmccue g...@github.com:rmccue/my-php-fork.git $ git fetch github-rmccue $ git merge github-rmccue $ git push php-src master The only difference as far as pull requests go is the one-click interface on the GitHub site (which I don't like personally, since you can't test before pushing). -- Ryan McCue http://ryanmccue.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
Ferenc Kovacs wrote: - which vcs would you prefer to use for your current work on the php project - which vcs will you continue to use what ever anybody else thinks you should be using? I'm running hg into github transparently for those projects that have already jumped lemming like ... and I put up with the crap that results from it :) I don't see github as any advantage, just a complete stranglehold on those parts moved to it, which will not then integrate with a decent project infrastructure such as php ALREADY HAS! -- 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] [VOTE] Choosing a distributed version control system for PHP
On Fri, Aug 26, 2011 at 2:28 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Fri, Aug 26, 2011 at 8:48 AM, Lester Caine les...@lsces.co.uk wrote: David Muir wrote: FWIW, PEAR is already moving to GitHub. So who dictated that There should at least be a little consistency in PHP and this is just another example of everybody just doing what they want and sod the rest of us :( PEAR is very different than the core. PEAR is inherently split up into small sub-packages that are easily maintained using separate version tracking. You could say PEAR is much like PECL, but there are still plenty of differences. We have a group of elected officials which (mostly) make final decisions, and we also have many individual developers that like to do what they want with their libraries. PEAR developers have long been able to use other publicly available version control systems. Yes the main repo has been with PHP, until svn.pear.php.net was set up for PEAR2 and subsequently moved back to PHP infrastructure once svn.php.net was set up. Just in the past few months or we've moved all of PEAR2 to git, and PEAR packages are individually moved over at will. the pear group decided that obviously. btw. I thought that only the pear2 infrastructure (site, packages) are moving to github. PEAR2 was the first, yes. For PEAR(1) our QA team has focused on unmaintained packages. It takes a lot of manpower to vet new contributors by requesting patches and building enough trust that we're OK granting them svn.php.net access. We've recognized that it's easier to get new/external contributions on github, which is very important when maintainers leave and our QA team has to take over. -- Brett Bieber -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
I'm fine with git and I think moving to something like that together with up-to-date tools to contribute (or review patches etc.) will help a lot. But I would prefer to keep the (core) infrastructure at PHP internally. It's just *so* much easier to integrate tools, add things like hooks for the bugtracker or whatever. Having people develop part of a project on github then is surely fine - but php-infrastructure would still be the official core imho. In this discussion I previously mentioned the TYPO3-community (which I guess stand for a lot of others) who integrated a review-system based on gerrit into their forge (actually a RedMine-based system; including bugtracker etc.) And that integration has helped a lot - both in openness/ease of use as well as actually getting the job done. It looks like the basic vote goes in the git-direction - first step taken :-) But I hope we'll find a wise decision on how to further continue in this matter afterwars. PS: Thank you all for your time and work in this matter. Regards, Stefan On 08/25/2011 09:08 PM, Ilia Alshanetsky wrote: If we do decide to make a VCS change the vote should be fairly one sided for option of choice as this has a fairly broad impact on our development process. On Wed, Aug 24, 2011 at 5:03 PM, David Soria Parra d...@php.net wrote: Hi Internals,, after 3 weeks of discussion, I think we are ready to start voting on the DVCS RFC. If you think something is missing or should be explained in more detail, let me know. Votes can be found here: https://wiki.php.net/rfc/dvcs/vote The RFC can be found here: https://wiki.php.net/rfc/dvcs Voting will be opened for 2 weeks and end on Sept. 7 at 12 pm. - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
Gwynne Raskind wrote: On Wed, Aug 24, 2011 at 19:03, David Soria Parrad...@php.net wrote: Those wanting to use git and git workflows have a disadvantage when we stay with SVN. Choosing a VCS happens from time to time and sometimes your favorit is not the winner. I personally would love to see PHP moving to hg, but if more people like git more, the hg people have to deal with it. Agreed on both counts. It _is_ nice to see that I am not alone in preferring hg ... Sometimes it does seem that I'm in a minority of 1. The RFC points out that there will be modules. We will_not_ copy the current SVN history into one big repo. In fact having everything, pecl, php-src and co in one repository does not make sense. The original plan called for the SVN repo to be split up at some point in the future, but DVCS gained traction and SVN went without any attempts by anyone to put a proper workflow of any kind in place. And I think this is the point. With the right structure in place then it _will_ be easier for cross dvcs working. The current plan calls for all of php-src to be a single repo, with rules for moving extra modules in and out. That is the single repo I am referring to and potentially it will be as unwieldy as the libreoffice setup? It _is_ about time that splitting things up was considered in a little more detail so we can work on every module with the same ease as 'extra' extensions are now currently managed? Even the argument that one needs to see all the history at once has the alternative view that just seeing commits for a single module would be helpful? ( Note Pierre - I'm not using upper case for emphasis - I started text messaging when the printers only had upper case so I'm still learning these newfangled ways :) ) -- 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] [VOTE] Choosing a distributed version control system for PHP
On Wed, 24 Aug 2011, Stas Malyshev wrote: On 8/24/11 2:03 PM, David Soria Parra wrote: after 3 weeks of discussion, I think we are ready to start voting on the DVCS RFC. If you think something is missing or should be explained in more detail, let me know. I'm not sure choosing DCVS by vote is actually a good way to go here. I think we need much more input from people that maintain all the infrastructure we're using now and would be doing the move. If we don't have people committed to making it happen majority-based vote is useless IMHO. I agree, and I also think that before people can make a choice they need to have played with all the options. Just picking git because that's what you heard of and what all the fan boys like is *not* the correct way to go. In order to make a choice, and even consider switching away from SVN, something that *works* just fine, you need to know the systems (ie, git and hg). cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
On 25/08/11 11:15, Derick Rethans wrote: On Wed, 24 Aug 2011, Stas Malyshev wrote: On 8/24/11 2:03 PM, David Soria Parra wrote: after 3 weeks of discussion, I think we are ready to start voting on the DVCS RFC. If you think something is missing or should be explained in more detail, let me know. I'm not sure choosing DCVS by vote is actually a good way to go here. I think we need much more input from people that maintain all the infrastructure we're using now and would be doing the move. If we don't have people committed to making it happen majority-based vote is useless IMHO. I agree, and I also think that before people can make a choice they need to have played with all the options. Just picking git because that's what you heard of and what all the fan boys like is *not* the correct way to go. In order to make a choice, and even consider switching away from SVN, something that *works* just fine, you need to know the systems (ie, git and hg). +10. I think a vote is prematured right now. Cheers. -- Ivan Enderlin Developer of Hoa http://hoa.42/ or http://hoa-project.net/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/25/2011 11:28 AM, Ivan Enderlin @ Hoa wrote: On 25/08/11 11:15, Derick Rethans wrote: On Wed, 24 Aug 2011, Stas Malyshev wrote: I agree, and I also think that before people can make a choice they need to have played with all the options. Just picking git because that's what you heard of and what all the fan boys like is *not* the correct way to go. In order to make a choice, and even consider switching away from SVN, something that *works* just fine, you need to know the systems (ie, git and hg). +10. I think a vote is prematured right now. so what do you suggest? We talk about the topic for 3 weeks now, and I think waiting any longer will not make more people familar with HG. So how do you make people take a look at the VCS in question? I'm open for suggestions. People now have 2 weeks to try out PHP by using the mirrors from either git.php.net or hg.php.net and see how their favourite system works. For me it seems most people don't even read the RFC and the recommendation, so I don't expect them to try out the VCS, but I don't have a clue how to change it. Joking: Next time I'll add a survey that you need to complete successfully before being alllowed to vote ;). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOVhfNAAoJEAT0aMuPE7Z1zukP/2IrTehCAE2AU+3CFSwh05NI san2ncCOfk3tdn6zOuc+4rYGWfSfixqjC0Xre7nma8sRb14zRt1kpzB5xA6EL2i9 SgqfPEUcpzPAF5QkoNrnR9FnZfFK/y/QXTRaupdk/ApLg2rdwegG2BzdB5AiofN7 Q1kxTlVBnwlizPH4J/0/H0kzm9/spkRhWkXslVtvkhVy/7yZH7I7R8kd+voy+6bE jmYuI7hS4Jf2/T0OFA9Js2V3sopOwOy7tuutEUqZ30EXjrE0UKFGs9eiGuBJaMF3 MLgvlSa6tcaAD+yJ8tLraJ1awUNl29kPT2QTJZQkgkJ07iKqPjipJu5jYRLQ6qdy kPuec7gUWC4jzrdmCsvtB1fdEGKWiCXspnP0KgGXjVmqreSvZBabiZm0fOEHqHST foqV7weQe/4wZd3n8UxTsk/Pd27OU5uXllkApsy123d7rV0hv9CEPy5WI7nlWsnB +necXTfdUeOFV2Vdgw7mDPXxf5vIC6t/rXiO2UjGd0QUZz9rxnb+JjQ5CAIpgeZz JVqXJH0RbVa7rIcxBctRmvZ/qq9oEQ9C4Du5vCSr8vOW7PKFJUo7QODd9cDbtBsS 0TnX8diqpw1JaXblIKrYmsUANkIiHLpynT3W9SZeCqdUjt8weiF8xAxbJKkA9/Tj ZE87iAbx3L+GfGNJ5ayz =Q5uu -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
On 25/08/11 11:37, David Soria Parra wrote: On 08/25/2011 11:28 AM, Ivan Enderlin @ Hoa wrote: On 25/08/11 11:15, Derick Rethans wrote: On Wed, 24 Aug 2011, Stas Malyshev wrote: I agree, and I also think that before people can make a choice they need to have played with all the options. Just picking git because that's what you heard of and what all the fan boys like is *not* the correct way to go. In order to make a choice, and even consider switching away from SVN, something that *works* just fine, you need to know the systems (ie, git and hg). +10. I think a vote is prematured right now. so what do you suggest? We talk about the topic for 3 weeks now, and I think waiting any longer will not make more people familar with HG. So how do you make people take a look at the VCS in question? I'm open for suggestions. I know. It's a difficult choice. But if we change our VCS for a DVCS, we do it for contributors or maintainers? If maintainers are the most concerned people, they should give a try to Hg and Git for a period longer than 2 weeks (2 months seems to be a reasonable period, 1 month with Hg, 1 month with Git). For the moment, the vote is opened to contributors. Maybe it's not a good “target” for the vote. People now have 2 weeks to try out PHP by using the mirrors from either git.php.net or hg.php.net and see how their favourite system works. For me it seems most people don't even read the RFC and the recommendation, so I don't expect them to try out the VCS, but I don't have a clue how to change it. I don't too. I think Git is more complicated than Hg and I regret the way the vote is changing. But, I repeat, I think the target for the vote is not appropriated. Joking: Next time I'll add a survey that you need to complete successfully before being alllowed to vote ;). s/Joking/Todo/ :-) Best regards. -- Ivan Enderlin Developer of Hoa http://hoa.42/ or http://hoa-project.net/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/25/2011 11:56 AM, Ivan Enderlin @ Hoa wrote: On 25/08/11 11:37, David Soria Parra wrote: On 08/25/2011 11:28 AM, Ivan Enderlin @ Hoa wrote: On 25/08/11 11:15, Derick Rethans wrote: On Wed, 24 Aug 2011, Stas Malyshev wrote: I agree, and I also think that before people can make a choice they need to have played with all the options. Just picking git because that's what you heard of and what all the fan boys like is *not* the correct way to go. In order to make a choice, and even consider switching away from SVN, something that *works* just fine, you need to know the systems (ie, git and hg). +10. I think a vote is prematured right now. so what do you suggest? We talk about the topic for 3 weeks now, and I think waiting any longer will not make more people familar with HG. So how do you make people take a look at the VCS in question? I'm open for suggestions. I know. It's a difficult choice. But if we change our VCS for a DVCS, we do it for contributors or maintainers? If maintainers are the most concerned people, they should give a try to Hg and Git for a period longer than 2 weeks (2 months seems to be a reasonable period, 1 month with Hg, 1 month with Git). For the moment, the vote is opened to contributors. Maybe it's not a good “target” for the vote. I think we are mostly concerned with contributers, nevertheless, if people like to have more time, I have not problem with extending the voting period to 4 or 6 weeks. You can always change your vote if you find out another VCS is more suitable. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOVhzlAAoJEAT0aMuPE7Z1SB8QAICKk8PB+gVXSoq5c61oV7qy yO4TFBbN8z/8f4KBpk1ai1BYP4VWESSXi9oJl/hZBwXFMZlBoa6a8lMU7wA431yK pUQBhWXCBHfUlVXF4/PBWS6F2pvrRhHZFG/gexANurnPEmQD4idQnjUb98SkuTtQ rA+9O3ON5ybUis8WZ1P23WjxTv6RFwU0EK2QfzhP9PXcDiXxiJhMAcNvUO10htdT JPKabjJsDTCixRCf21UGsatX82rLdhy7NbWmEz0i95qjOYpps6qUqkIn+9bHVOsC YXzBbMwnWRHeiafgf8N431mSEurlP5Oj8W9P+BHatd2YGO3TZVANKzEAeWNdQDMk pnGtpP+XK9M7+OvnyX3/qX08s+g3vt0gCLMrI451lCJ7bq5lV+q6SXopzE5kVkBG WA04TDh/6x1N96ijq12bCLIe+/DtEKsEDLvCFYt7IrGxCzbtepJa27RzYdkw378e vMlHSlOt9h64tBV9Er814STEkr6S00VQLnJOSmQjB9QL/5vZ7HeWQK7kR4OuSaxN OaTBSkU3BHVlO6CPujm3GhchtI0Vf6frREVA+0AdHJmBbQtxijF36xeP2ZFIqPxw tbwI+wScfmD0ZMWtvy1DfL6E0EukElUYqrkdrnjqohRcw85NguUM733rBmfnXPfv 7x1fsSF8iS78jgDRF5SA =BLPg -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
I'm not familiar enough with Mercurial to properly vote, but am guessing we'll move to Git. Git is popular because Github is popular, and Github is popular because it's awesome. But I think we should skip git.php.net and mirrors/bridges, and simply move to Github. And this means people who maintain Git for a living would maintain it, while we can focus on developing PHP. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
2011/8/24 David Soria Parra d...@php.net: Hi Internals,, after 3 weeks of discussion, I think we are ready to start voting on the DVCS RFC. If you think something is missing or should be explained in more detail, let me know. I won't transfer the discussion over here but; I don't want to move to a new system we we did it just a few years ago, as Rasmus said long before we moved was that we want to find a solid system that could hold out just as long as the old setup. I don't have a problem by using SVN, nor merge as we have been good at keeping files in sync so its easy to merge patches, much easier than the old unicode-trunk. That being said; I agree with Stas that having a vote is not a good way to actually make a choice here, but it gives a hint of those that voted, as I'm sure that there are many more actively working on the project like PEAR. PECL and Doc guys thats not gonna vote because they don't follow Internals. But -1 from me. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
If we do decide to make a VCS change the vote should be fairly one sided for option of choice as this has a fairly broad impact on our development process. On Wed, Aug 24, 2011 at 5:03 PM, David Soria Parra d...@php.net wrote: Hi Internals,, after 3 weeks of discussion, I think we are ready to start voting on the DVCS RFC. If you think something is missing or should be explained in more detail, let me know. Votes can be found here: https://wiki.php.net/rfc/dvcs/vote The RFC can be found here: https://wiki.php.net/rfc/dvcs Voting will be opened for 2 weeks and end on Sept. 7 at 12 pm. - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
On 08/26/2011 04:12 AM, Kalle Sommer Nielsen wrote: 2011/8/24 David Soria Parra d...@php.net: Hi Internals,, after 3 weeks of discussion, I think we are ready to start voting on the DVCS RFC. If you think something is missing or should be explained in more detail, let me know. I won't transfer the discussion over here but; I don't want to move to a new system we we did it just a few years ago, as Rasmus said long before we moved was that we want to find a solid system that could hold out just as long as the old setup. I don't have a problem by using SVN, nor merge as we have been good at keeping files in sync so its easy to merge patches, much easier than the old unicode-trunk. That being said; I agree with Stas that having a vote is not a good way to actually make a choice here, but it gives a hint of those that voted, as I'm sure that there are many more actively working on the project like PEAR. PECL and Doc guys thats not gonna vote because they don't follow Internals. But -1 from me. FWIW, PEAR is already moving to GitHub. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
Hi Internals,, after 3 weeks of discussion, I think we are ready to start voting on the DVCS RFC. If you think something is missing or should be explained in more detail, let me know. Votes can be found here: https://wiki.php.net/rfc/dvcs/vote The RFC can be found here: https://wiki.php.net/rfc/dvcs Voting will be opened for 2 weeks and end on Sept. 7 at 12 pm. - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
Hi! On 8/24/11 2:03 PM, David Soria Parra wrote: Hi Internals,, after 3 weeks of discussion, I think we are ready to start voting on the DVCS RFC. If you think something is missing or should be explained in more detail, let me know. I'm not sure choosing DCVS by vote is actually a good way to go here. I think we need much more input from people that maintain all the infrastructure we're using now and would be doing the move. If we don't have people committed to making it happen majority-based vote is useless IMHO. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/2011 11:15 PM, Stas Malyshev wrote: Hi! On 8/24/11 2:03 PM, David Soria Parra wrote: Hi Internals,, after 3 weeks of discussion, I think we are ready to start voting on the DVCS RFC. If you think something is missing or should be explained in more detail, let me know. I'm not sure choosing DCVS by vote is actually a good way to go here. I think we need much more input from people that maintain all the infrastructure we're using now and would be doing the move. If we don't have people committed to making it happen majority-based vote is useless IMHO. Sure. I wrote the RFC because I plan to implement it. I will make it possible for either Git or Mercurial, but as stated, I prefer doing it with Mercurial. The vote is not a 100% we do it, but rather a: we would like to have it that way. So if people choose Bazaar, someone has to come up with a solution. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOVWrAAAoJEAT0aMuPE7Z1W0EQAK59Xw/gvwLI4qhR7pZ/kuJQ d4+Qs3wP2jipZUtq+6STvZdPD1Yf9PgyM9O+nshF73VtM91gY259CQ62QrDIE/6X mKes7T+3WWdQoEbKPCBA2uYiriVT2feS9DpiZnkz8oarXgFwRy+iryEeLGxCSovt Swy0xvpM1V6zt1ZxgYMhQDKF3eJCd7K6DctKyNScwzqH2N41HFnR/bhk1ZOT172B e/qXy3Bw0k3jo6khq2bjPlAID1yecmVuHjxtx5sxX/cTkyfrUWeYcUU49BIFRHa5 ZZe9JyfO2HcTi2+V5ni097Q2FYOOV7CuLdMaZqf26L0oZIttn+3CSNTcw+77cE98 aNB9+n1vkXPBuVpyz0mZz2/BYHpX4SjPHdgmmgZHlA9xz8RRbYypyK1TraoCiVOO 86utV3+TAsat+zl4hkvbtLap0VO6/9/XuFLdkKzhjMpP+8LkXo/5/supP2oyoYrP rHNyvdiH8gV6fQQyXoikSxYaCtLrAVwoC6mc8OIIQsiT0INkB5tP5g9hbuh+uxO2 nFT5qgYDhkXbNDYG7qHFGH29ijjARcer0NYekUtnZvViC3PGQ4vEZhDvjcis8uDr LrqzD3surZJX4CLUF0i13TKiNS9S8s/orV9zdI93I18gFXf6wAPPUZJUXVLsgSic +Gir6bAS7NVZs73KtoFL =5Hhp -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
On Wed, Aug 24, 2011 at 11:15 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 8/24/11 2:03 PM, David Soria Parra wrote: Hi Internals,, after 3 weeks of discussion, I think we are ready to start voting on the DVCS RFC. If you think something is missing or should be explained in more detail, let me know. I'm not sure choosing DCVS by vote is actually a good way to go here. I think we need much more input from people that maintain all the infrastructure we're using now and would be doing the move. If we don't have people committed to making it happen majority-based vote is useless IMHO. I think that David is the most commited person for this cause, and currently he is the ?only? one who actually does something for the progress. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
On 2011-08-24, Ferenc Kovacs tyr...@gmail.com wrote: On Wed, Aug 24, 2011 at 11:15 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 8/24/11 2:03 PM, David Soria Parra wrote: Hi Internals,, after 3 weeks of discussion, I think we are ready to start voting on the DVCS RFC. ??If you think something is missing or should be explained in more detail, let me know. I'm not sure choosing DCVS by vote is actually a good way to go here. I think we need much more input from people that maintain all the infrastructure we're using now and would be doing the move. If we don't have people committed to making it happen majority-based vote is useless IMHO. I think that David is the most commited person for this cause, and currently he is the ?only? one who actually does something for the progress. There are people behind the scene like Gwynne, Johannes, Rasmus, Pierre and Nils Aderman from phpBB who helped. Just wanted to mention their names at least once :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
On Wed, Aug 24, 2011 at 11:15 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 8/24/11 2:03 PM, David Soria Parra wrote: Hi Internals,, after 3 weeks of discussion, I think we are ready to start voting on the DVCS RFC. If you think something is missing or should be explained in more detail, let me know. I'm not sure choosing DCVS by vote is actually a good way to go here. I think we need much more input from people that maintain all the infrastructure we're using now and would be doing the move. If we don't have people committed to making it happen majority-based vote is useless IMHO. It is the same for everything, that does not make the vote useless. About people maintaining our infrastructure, not much actually maintains svn, and that won't change anything if we move to something (except easiness) from a backupco pov. And unlike the last time we switched to another VCS, this time we will have a clear decision process :) -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
David Soria Parra wrote: I'm not sure choosing DCVS by vote is actually a good way to go here. I think we need much more input from people that maintain all the infrastructure we're using now and would be doing the move. If we don't have people committed to making it happen majority-based vote is useless IMHO. Sure. I wrote the RFC because I plan to implement it. I will make it possible for either Git or Mercurial, but as stated, I prefer doing it with Mercurial. The vote is not a 100% we do it, but rather a: we would like to have it that way. So if people choose Bazaar, someone has to come up with a solution. I think the problem here is that _if_ the majority are already committed to git anyway, those of use who are using hg or something else are going to be at a disadvantage since it is now obvious that cross working will not work especially if everything is rolled into the one super repo. Even the 'decision' to roll everything into single repo copying the current SVN history _should_ be something that is put to a vote. The problems of testing _sections_ of this vast code base and tracking bugs against them should be a perfect reason for a much more modular approach so we can test each module as a separate package. And the process is something that _does_ change depending on the different DVCS's. So simply voting on the current rfc seems a little pointless at the moment? -- 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] [VOTE] Choosing a distributed version control system for PHP
On 2011-08-24, Lester Caine les...@lsces.co.uk wrote: David Soria Parra wrote: I'm not sure choosing DCVS by vote is actually a good way to go here. I think we need much more input from people that maintain all the infrastructure we're using now and would be doing the move. If we don't have people committed to making it happen majority-based vote is useless IMHO. Sure. I wrote the RFC because I plan to implement it. I will make it possible for either Git or Mercurial, but as stated, I prefer doing it with Mercurial. The vote is not a 100% we do it, but rather a: we would like to have it that way. So if people choose Bazaar, someone has to come up with a solution. I think the problem here is that _if_ the majority are already committed to git anyway, those of use who are using hg or something else are going to be at a disadvantage since it is now obvious that cross working will not work especially if everything is rolled into the one super repo. Those wanting to use git and git workflows have a disadvantage when we stay with SVN. Choosing a VCS happens from time to time and sometimes your favorit is not the winner. I personally would love to see PHP moving to hg, but if more people like git more, the hg people have to deal with it. Even the 'decision' to roll everything into single repo copying the current SVN history _should_ be something that is put to a vote. The problems of testing _sections_ of this vast code base and tracking bugs against them should be a perfect reason for a much more modular approach so we can test each module as a separate package. And the process is something that _does_ change depending on the different DVCS's. So simply voting on the current rfc seems a little pointless at the moment? The RFC points out that there will be modules. We will _not_ copy the current SVN history into one big repo. In fact having everything, pecl, php-src and co in one repository does not make sense. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
On Wed, Aug 24, 2011 at 19:03, David Soria Parra d...@php.net wrote: Those wanting to use git and git workflows have a disadvantage when we stay with SVN. Choosing a VCS happens from time to time and sometimes your favorit is not the winner. I personally would love to see PHP moving to hg, but if more people like git more, the hg people have to deal with it. Agreed on both counts. The RFC points out that there will be modules. We will _not_ copy the current SVN history into one big repo. In fact having everything, pecl, php-src and co in one repository does not make sense. The original plan called for the SVN repo to be split up at some point in the future, but DVCS gained traction and SVN went without any attempts by anyone to put a proper workflow of any kind in place. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
