On 7 August 2011 21:50, David Soria Parra <d...@php.net> wrote: > Hi Internals, > > Distributed Version Control Systems (DVCS) getting more and more > popular. In fact they have been discussed within the PHP community and > on Internals a few times. It came to my attention that more and more > people like to see PHP move to a DVCS to solve some of the current > issues (and get other ones). > > I was asked to put together a RFC, and so here we are. I've created > an initial draft. It is mostly based on the very good Python PEP-0374. > It compares Git and Mercurial. > > https://wiki.php.net/rfc/dvcs > > There are reasons for choosing these systems: > * Both are quite popular > * I know them > * Most PHP devs that I know, know at least on of them > * Big projects have recently moved to them, they have > similar requirements like PHP > > The RFC is far from done, so please help me finishing it and get it out. > > This is a call for participation to help to get a (probably heated) > discussed started and work on the RFC to make it good enough to finally > choose a system or, and that is a valid option, stay with SVN. > > So if: > - you are interested in DVCS > - know a little bit about PHPs requirements for a DVCS > - are not a fanboy > > Feel free to discuss this and add your thoughts to the RFC. I would > love to not do this on my own. Feel free to catch me on IRC (dsp_ on > php.pecl) and discuss it. > > NOTE: this is not the place for any religiouise discussion about git vs > mercurial whatsover. if you have nothing else to add than "hg is $*** > anyway" or think hosting platform XY will solve all our problems > without reading the RFC carefully, please post to alt.relgion.* and not > here. > > > - David
I feel I have a major objection to using a DVCS for PHP. Currently, a single source provides a sense of authority. If bad code is committed, it will be quickly dealt with. If good code is incomplete it may be withdrawn or fixed. In most cases the features that exist in a branch are well thought out and many clever brains have seen it and interacted with it to make it what it is. So, when someone like me comes along, someone capable of building the code and playing with it at a very minor level, I can be sure that if things don't work, it is probably me that's broke it and that I can rely on the branch to contain good working code. OK. I know ITRW, things do get left unfinished or plain broken. But it isn't as if the code belongs to a single person who may have not spent all their time with it. Whilst I am happy to use my own builds on my dev setups, I'm also happy to rely on the official releases from The PHP Group. Now let's envisage a DVCS. There will be (not might be, but will be), multiple, and potentially conflicting/incompatible, versions available. Which do I choose? If everyone is capable of forking PHP, which is the official one? In the event of a single official repo, then why bother with a DVCS? (I'll admit I'm naive on the true requirement of DVCS, as I think SVN works very well). The main thing I'm worried about is if feature X splits the core devs so much that there are 2 competing repos, both with a significant number of core devs supporting each repo, how do I choose which is which? If my abilities include being able to code at the core level, which should I support? Both? All 3, 4 or 10 different forks? Having a single repository for the code makes the code the official, authoritative version. A DVCS will have too many champions and I feel would drastically dilute that authority. Regards, Richard. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
