On Fri, Aug 12, 2011 at 3:01 PM, Lester Caine <les...@lsces.co.uk> wrote: > Stas Malyshev wrote: >>> >>> Sandboxes and development branches are the right way to go, but could >>> actually >> >> Branches are different things than github forks, for different purposes. >> Branch is a project, fork is a workspace. You can have multiple people >> work on a project, using multiple workspaces. > > That is not how Drupal seems to be using git ... > http://drupal.org/node/803746#clone - See 'Creating a Working Branch' > > Personally that is not how I'd like to see php going ... but I'm more than > happy with my own hg workspace locally anyway :)
I think any kind of RFC vote is going to meet a lot of resistance simply based on the fact that a lot of people on this list do not appear to be very familiar with dvcs and the pros and cons of moving to one of the dvcs offerings. Trying to find the best solution in terms of technology (git vs hg), structure, workflow, etc is an effort in futility at this point. I think it would be better to pilot some different options and ease people into the transition from a vcs to a dvcs. One idea that springs to mind is allowing pecl packages to live on google code, github or bitbucket. That allows developers to freely play around with svn, git or hg. While that may seem odd, some of us are already doing it (ex: https://github.com/andreiz/php-memcached). I am sure this brings up all sorts of problems and issues, but that is the point. Moving svn to a dvcs is less of a technical change and more of a paradigm shift in the fundamental way a user interacts with version control. As a long time dvcs proponent and user, I support the move to distributed version control. I just hope it is done right. -- Herman Radtke hermanrad...@gmail.com | http://hermanradtke.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
