>> >> I am not in favour; I will repeat what I just wrote to Davey: >> >> DVCS is also a lot more egocentric thing, instead of >> >> collaboration. You want your stuff exposed to as many developers as >> >> possible instead of walled gardens. It might be easy enough to >> >> share, but discovery is a lot harder.
Developers can already wall themselves off now with the github mirror. Also, taking a peak at the linux dev mailing list I see lots of collaboration going on. It makes sense that a developer wanting to discuss a new feature or patch will push that branch to origin. What a DVCS does allow for are branches for each specific project/patch and incremental commits within that branch. That keeps project/patch commits together and also side-steps the entire issue of cherry-picking. At work we use git and usually have 6 project branches with competing and interweaving timeframes. Each developer has upwards of 50 branches local to them (heck I recently had 105 until I did some cleaning yesterday) that feed the project branches. We manage this with very few problems and is not something we could do with cvs or svn. >> > >> > Ignoring the problems of actually using github I think this is >> > exactly the problem we are finding with those projects that have >> > pushed over to git. MANAGING what is allowed back into some master >> > copy of the code base is the bit that is a lot more difficult than >> > with current arrangements. The result is several versions of the >> > same projects simply because people are doing their own things and >> > then nobody knows which version to pull from. The release manager >> > has to un-pick what should be merged and even on a small project >> > this is time consuming. If everybody with their own agenda for PHP >> > starts doing their own builds we will end up with even more branches >> > since they will just be publishing them ;) >> >> http://progit.org/book/ch5-1.html >> I think we could go with either an Integration Manager kind of workflow, or >> with the Dictator and Lieutenants (that is used for the linux development). >> either way, with good merging tools, the integrations isn't such of a >> problem. > > Whatever workflow we prefer is not what is guaranteed to happen. I agree > totally with Lester here. DVCS fragments the development team. DVCS does not cause fragmentation. DVCS is a tool. How a development team uses that tool is up to them. I don't think anyone seriously considering a migration to git is thinking that there are no problems. However, the problems Lester is describing are similar to the problems we have now: people checked in all kinds of changes to trunk and nobody knows how to pick them apart to make a stable build. In my experience, managing DVCS is less work than managing cvs/svn. Sure, individuals and entire development teams can shoot themselves in the foot if they use DVCS incorrectly. But, I would rather use a sharp tool (like git) than a dull one (like svn). -- Herman Radtke hermanrad...@gmail.com | http://hermanradtke.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
