Hi, very glad this topic has resurfaced and I honesly think using a DVCS will be a game-changer for PHP. Just wanted to drop a couple of answers I've dedicated some time in at SE, several diagrams, to-point explanations and references that might be of uso to clear out introductory topics.
http://programmers.stackexchange.com/questions/35074/im-a-subversion-geek-why-i-should-consider-or-not-consider-mercurial-or-git-or/35080#35080 http://programmers.stackexchange.com/questions/77475/how-to-choose-between-git-and-mercurial/77663#77663 http://programmers.stackexchange.com/questions/31558/version-control-for-small-team/31564#31564 In brief: either git or mercurial will be a great option, but if the majority of the dev-base has less experience with DVCS, there might be more frustration if you get introduced to DVCS with git than with mercurial, same goes for potential collaborators, so mercurial —IMHO— does lower the barrier of entry. Lots of people choose git over mercurial over github, but bitbucket is improving more frequently under Atlassian's watch. Since the project is big enough, git might be a better choice to accommodate PHP's most complex code workflows —which I'm totally unfamiliar with—. Mercurial, OTOH, has less power tools to play with than with wgit, but unless you really really need them, my take on this is: go with mercurial and lower the collaboration barrier as much as you can. Best regards, David On Mon, Aug 8, 2011 at 8:01 PM, David Muir <davidkm...@gmail.com> wrote: > On 09/08/11 01:07, Lester Caine wrote: > > David Muir wrote: > >> John Szakmeister, who is a Subversion developer himself, has a good > >> comparison of svn, hg, bzr and git: > >> > http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ > >> > >> > >> Long story short, his company went with git. > > > > Makes good reading ... many other comparisons are now getting long in > > the tooth, and so don't cover the current playing field. Still it > > looks like 'best of a bad job' rather than 'this wins hands down' and > > does make a fair comparison of all the current problems, but I think > > the fact that he has not investigated submodules may actually negate > > their final results :( This was the main area that I needed to work > > well, but is still work in progress everywhere? > > > > He did mention submodules as a Pro for git, but you're right, he didn't > compare it with Hg's subrepos and subhg and Bzr's nested trees, > bzr-externals and scmproj. I have a feeling that git's native support > for it is much more mature than the others. That said, it's not a > feature I've looked into myself as it's not something I've actually needed. > > Cheers, > David > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
