On Nov 25, 2010, at 9:05 AM, Derick Rethans wrote: > On Thu, 25 Nov 2010, Davey Shafik wrote: > >> The goal then was to essentially take the 5.3 branch, create a 5.4 >> branch, cherry pick commits to trunk and apply them to the 5.4 branch >> and end up with a stable build. Unfortunately, subversion merging >> sucks. > > This has nothing to do with any sort of version control sucking. Cherry > picking is hard! It only works if you get one feature in one commit, > instead of many several, with other changes in between, without many > dependices between patches. PHP isn't like that, especially with > Dmitry's engine changing patches.
While it's true the tools are not to blame, they're not HELPING the situation as much as some people seemed to think when the plan was thought out. Everything you say simply backs up my point that SVN is not the right tool for the model that seemed to be the goal. > >> This doesn't seem the ideal time to introduce a new toolchain, so >> sticking with SVN, we should maintain 4 branches, 5.2 (security only), >> 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC >> breaks), 6.0 (BC breaks). > > Four branches? Are you going to help? I'm not sure why you seem to think this is so difficult. 5.2 would (ideally) have very little work going on. 5.3 would have somewhat more work, but is also closed to 5.4 so committing to two branches would be somewhat easier. 5.4 wouldn't be released till all features are complete, then it too moves to a bug fixes+security release and 5.2 gets sunsetted (this is why we need more reliable schedules). If we have releases every 6 months, or every 12 months (for example), it would mean each X.Y would last 12 or 24 months respectively. > >> Non-agreed upon enhancements, potential BC breaks, all should be done >> in feature branches. > > That's a good theoretical point of view. And I maintain it doesn't work. > It makes it for example very difficult to try out multiple new features > at the same time; to say, to try to figure our whethr your app will > still works. It's also a lot more egocentric thing, instead of > collaboration. You want your stuff exposed to as many developers as > possible (that's also why I am not a fan of DVCS, because it reduces > that exposure drastically). Actually, it makes things easier, now you can simply do: svn co http://svn.php.net/r/php/php-src/branches/PHP_5_3 php-5.3 svn diff http://svn.php.net/r/php/php-src/branches/traits http://svn.php.net/r/php/php-src/branches/PHP_5_3 | patch ./php-5.3 svn diff http://svn.php.net/r/php/php-src/branches/derick-typehints http://svn.php.net/r/php/php-src/branches/PHP_5_3 | patch ./php-5.3 It means you get easy contiguous patches from any branch, over any number of commits (solving your issue above) And, as already pointed out, the collaboration possible through github is far more than we currently enjoy via SVN and ML/IRC today - but again, I don't want to propose git as a solution. As for talk of 6.0 as opposed to 5.4, nobody is going to risk putting their BC compatible features in a 6.0 release and then take 2 years to be adopted unless we force it (the committing to 6.0, not the adoption), when they can just create 5.5, 5.6, 5.14 and get it out before the stigma of the jump to 6.0 adoption. I don't have a solution for this that doesn't suck (forcing 6.0, or managing two branches, with all the same features, 5.x without the BC breaks, 6.0 with) - Davey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
