Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50716
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain darkrainfall.org from 208.97.132.202 cause and error)
DomainKey-Status: bad (key type)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=darkrainfall.org; h=content-type
	:mime-version:subject:from:in-reply-to:date
	:content-transfer-encoding:message-id:references:to; q=dns; s=
	darkrainfall.org; b=V1DX6PEvMVfnrNCwjmzNPWgSpetHSg4ZP4qs6r50P/75
	B4hvKmZcyxlGvosxjIckr3jl8/b3xZpAEKQHyrsmWtxdy0yihDe5iSZ9lXNFdlIo
	o71HDd4JK87mgDxIy/TVOE8pteCg+mOQpB8g7TQRtk0v0fANnQwhLUw9MxpzRpM=
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1082)
In-Reply-To: <4CF3700C.8040105@lsces.co.uk>
Date: Tue, 30 Nov 2010 04:49:27 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <5F486364-2071-4F39-8969-80BFF53A3377@darkrainfall.org>
References: <AANLkTinnOnk2FuxdriyksW4zGGCmauWP7XLBqkTVLMgU@mail.gmail.com> <4CEE0ADA.5010705@lsces.co.uk> <AANLkTimkPyL4=uCaf41cX2dgy4f+_EVJd-s7PpPoixG0@mail.gmail.com> <4CEE1327.7050405@lsces.co.uk> <9A.53.20008.2113EEC4@pb1.pair.com> <1291012292.2879.13.camel@clint-MacBookPro> <slrnif6pbv.752.dsp@experimentalworks.net> <4CF3700C.8040105@lsces.co.uk>
To: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] git anyone?
From: gwynne@darkrainfall.org (Gwynne Raskind)

On Nov 29, 2010, at 4:19 AM, Lester Caine wrote:
>>> I've not used git or hg much at all, but bzr has always satisfied my
>>> needs for DVCS, and has recently gotten much faster and more space
>>> efficient than it was in the past.
>> Sorry, but I think bzr is not a good fit. It's numerous changes to =
the
>> repository format make it impossible to use. It's either slow if you =
use an old
>> version, or it's incompatible with old clients, let's say on an old =
debian box.
>>=20
>> So I think php.net is better of using mercurial or git, but if we put =
together
>> an RFC for a migration, I'll make sure bzr is covered as well in an =
evaluation.
> Personally I would need a very good reason to add yet another DVCS to =
the mix here! I've not found bzr as easy to link to from hg as git is. =
In fact I've not actually got it to play at all as yet ... while hg does =
work into git with only the problems of managing multiple repo's which =
is still work in progress on both of them.
>=20
> That said, bzr does seem to handle the multiple repo's in a more user =
friendly manor? It is just a pity that there is NOT a single target =
solution for DVCS as everybody is currently scurrying off to their own =
corners :( The barriers have already been drawn rather then there being =
concensus on some sort of standard.


I think it's high time I tossed in my 1.682=A5(JPY) (according to =
current exchange rates)...

I've been out of the PHP dev community for some months now, so anything =
I say has to be taken with a grain of salt; I simply don't have the time =
right now to catch up in any detail on the current state of affairs.

That in mind, I was already disgusted with SVN by the time the move to =
it was finished. At the risk of drawing a bit of fire, I have to say I =
agree with Linus Torvalds' attitude about it, when he said (search =
"Linus Torvalds subversion" on Google for the reference) that it was =
pointless and that CVS couldn't be done right.

SVN ditched things CVS had that should've been kept. Sub-repo management =
(modules) and module merging/aliasing are the two I fought most with =
during the migration; externals were a BAD patch on the problem! SVN was =
trying to "do CVS right", but that simply doesn't hold together in the =
modern software development world. Centralized servers by themselves are =
an old model. Simple, but old. That's why DVCSs exist in the first =
place!

So yes, I think PHP needs to move past Subversion, which is being =
constantly held back by a model that's just too limited. The =
branching/merging nightmare seals the coffin, as far as I'm concerned.

Which DVCS do I think is best?

Git is the massive favorite out there at the moment, according to my =
Googling. I myself have never been able to fully get my head around it; =
someone said earlier in the thread that it's "a swiss army knife with a =
boom button", a sentiment I tend to agree with. Still, someone else also =
correctly said that the huge majority of devs in PHP right now do use =
it, and that can't be ignored. It is my observation that the Windows =
issues have been largely solved in more recent times. GitHub itself =
(while I would prefer something we host ourselves), is pretty easy to =
use.

I don't know much about Mercurial, having never used it, so I can't =
comment much on it. The fact that it continues to be prevalent at all =
versus Git says something for it, but it falls down against the ubiquity =
argument, as a quick glance suggests to me that the learning curve would =
actually be a bit worse than Git's. Its Web interface makes me cringe.

Bazaar is -my- current favorite, as its commands tend to translate =
almost directly from SVN's and while a minority, it has a passionate =
following (largely thanks to Ubuntu and MySQL, I think). But it being my =
personal favorite doesn't mean much. I also find Launchpad a bit =
incomprehensible, and Bazaar being written in Python feels a little odd =
to me. Don't we rely enough already on competing languages? :) =
(Mercurial also suffers from this.)

I am not going to attempt any kind of conclusion based on technical =
merits (branching/merging ability, sub-repo support, etc.), as I don't =
know what the status of these features is, and even if I did, I no =
longer have enough knowledge of PHP's current state to apply the =
knowledge.

So, I have to base my thought on what the most people are going to have =
the least trouble working with, and that's Git, hands down. There are =
more than enough people around the community with the full knowledge =
necessary to undertake the migration with minimum fuss; it's been =
pointed out that the kind of massive manual balancing I had to do for =
CVS->SVN would be completely absent.

I just wish I didn't have to also admit that Trac is a really great =
project management system. Unless things have changed drastically since =
I was last active, PHP still needs one. ^^;

-- Gwynne