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. > 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? > 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). Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
