On 2011-08-12, Lester Caine <les...@lsces.co.uk> wrote: > Johannes Schlüter wrote: > > > > Actually the real question here is WHY create a fork on github > > > > at all? The copy you are working on LOCALLY is the fork that you > > > > are developing on? Much of the stuff on github and the other > > > > DVCS server sites is redundant? You only need to publish your > > > > local changes to other developers who are working with you not > > > > to the whole world? > > since i can publish an experimental feature, get it > > reviewed/tested/improved before pushing it to the main tree. > > > > Mind that "other developers who are working with you" is potentially > > everybody on this list;-) > > But that is the point ... if everybody has their own published > 'experimental feature' repos, syncing those bits we are playing with > looks like a nightmare? Surly the point of DVCS is we share via some > central pot, and these experimental branches exist there? Having to > keep track of who's bits you are playing with is the messy bit :( And > it's that which has caused problems with other projects, where > 'extensions' have grown in secondary repos ... and become the official > extension. That is what I think people are just trying to flag up.
Actually, it's not a nightmare; it's incredibly easy, and actually helps keep features and bugfixes more sandboxed, and thus more easily reviewed and merged. As an example, let's say I as a developer want to develop feature Y for the language. I create a new branch locally, and start developing. As I near a point where it seems ready, I rebase from the canonical repository, and check to see if any conflicts occur between my code and what's come in on the main repo. If all looks good, I ask for review, and, after a few rounds of back and forth and some coding, again rebase, and then ask for somebody to merge. The nice part about this is it puts the onus on the individual developers to ensure they have clean patches -- if a merge request doesn't apply cleanly, you throw it back and ask them to submit again when it does. Now, let's say while I'm working on feature Y, I also tackle issues X, Z, and A. I do each of these in their own hotfix branches. The nice part is that there's easy, simple segregation between each fix, and I can move back and forth between the branches quickly and with no bleed-over. When it comes to the central repo, you have somebody or a team of people basically reviewing, merging, and pushing in pull requests. A release master is "king" or "queen" of a particular release branch, and is the one who decides if/when a feature is merged to that branch. The main thing is making it clear who is responsible for merging into a "master" branch, and who is responsible for merging into a release branch -- in other words, it comes down to processes. And, frankly, the processes are not terribly unlike the status quo -- the real question is what version control system is the best fit for that process. DVCS tools are (generally) optimized for quick branching, ease of merging, and minimizing commit size -- all of which could potentially benefit PHP development. -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
