Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52040
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type;
        b=BnLDcGh6/OeiKIIGiaFQTGhE4n1rizSMP7XMT5QtJUHtVin4L1Z8ArAAA//pqtQV23
         SqiwGMMxPUzTDE3lntoVlGQA2fay6fmj8ZIaHAVGwmdk8t3OUaau/lsRb3IhH18Qcyv8
         ftHMuMLuLTYJ/9z9vudIXz2S9n5VVNzR3qszY=
MIME-Version: 1.0
In-Reply-To: <4DB8DF0D.9020202@yahoo.com.au>
References: <4DB8CCA9.7040604@yahoo.com.au> <BANLkTik+wffarxWj-hzm_uHf2b70dUb_jw@mail.gmail.com>
 <BANLkTinZewZVgmNqzw_4tOs3ShmaxOcnrA@mail.gmail.com> <4DB8DF0D.9020202@yahoo.com.au>
Date: Wed, 27 Apr 2011 23:30:30 -0500
Message-ID: <BANLkTinBknEOUZ+kMx22ve0i0Jk_X57h2g@mail.gmail.com>
To: Ben Schmidt <mail_ben_schmidt@yahoo.com.au>
Cc: Drak <drak@zikula.org>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=0016e68e80269e096804a1f305e8
Subject: Re: [PHP-DEV] DVCS
From: dukeofgaming@gmail.com (dukeofgaming)

--0016e68e80269e096804a1f305e8
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Ben, I'm sorry I did a wrong remark there, but I see you saw what I
meant.

The nice thing about open source projects is that communities develop
naturally around them, it becomes an ecosystem, everything tends to lean
towards balance, when a change is intended to be made it should be allowed
to develop organically. Point here is: lets not try to force DVCSs but
rather keep the door open so the community can pass through it whenever it
feels ready, so the dilema of current devs vs potential devs never happens.

My advice here is =97if current devs are willing=97 to pilot test a DVCS on=
 a
small part of the project where it can be used primarily (as in not with
subversion); this would be a very healthy exercise to understand the why of
this generalized DVCS-ish concern.  Another advice is to open the discussio=
n
towards the choice of a DVCS in comparison to the project's interests and
demographics (e.g. if there are more windows users than mac/linux, mercuria=
l
would be preferred, if its the other way around && there is an underlying
git community, git might be best).

To all who doubt DVCS, this is a good read for you:
http://hginit.com/00.html

In relation to Drak's remarks, yes, I think the maturity of the tools has
contributed to its increased usage, and also, the very cool services around
them, such as github.com and bitbucket.org.

Finally, I think from here on, the conversation should be focused on findin=
g
a technical solution to the load problem (I'm not familiar with the setup,
but if I think of something I'll post it).

Regards,

David

On Wed, Apr 27, 2011 at 10:29 PM, Ben Schmidt <mail_ben_schmidt@yahoo.com.a=
u
> wrote:

> Just for the record....I didn't say popularity was a reason to use a DVCS=
.
> I said the popularity of DVCSes might cause server strain (if a lot of
> people want to convert the public SVN repo to a distributed one, download=
ing
> all the changes in the repo, which SVN really wasn't designed for, that
> would be a heavy load--and positively correlated to popularity: more
> popular, more conversions, more load).
>
> I agree with your closing point, though: I'd love to see us look for a
> low-load way of providing an Hg mirror and/or a Git mirror. I also think
> that either a mirror or a change of VCS may attract developers in the
> medium-term. However, I also think that current developers carry a lot mo=
re
> weight than potential developers, and it's important for them to be able =
to
> work in a way that is comfortable for them. So a mirror or two would be
> nice, and I'd push for that, but a change of official repo I will merely
> suggest be considered longer term.
>
> Ben.
>
>
>
>
> On 28/04/11 1:07 PM, dukeofgaming wrote:
>
>> Hi,
>>
>> I'm not a frequent poster in the list but I thought I'd really should gi=
ve
>> my 1 cent here when I saw "popular" being an argument for using DVCSs, i=
ts
>> not, and its neither fashion nor cargo cult, it is just a plain eye open=
er
>> experience of how neither SVN or CVS are the base of all versioning (two
>> of
>> its creators =97Brian Fitzpatrick and Ben Collins-Sussman=97 have acknow=
ledged
>> this by saying "sorry about that" with regards to Subversion) and that
>> better and more natural ways to collaborate and integrate code.
>>
>> I could provide an epically long argument here, but instead I'll link to
>> the
>> one I've already made, diagrams and graphics included =3D):
>>
>>
>> http://programmers.stackexchange.com/questions/35074/im-a-subversion-gee=
k-why-i-should-consider-or-not-consider-mercurial-or-git-or/35080#35080
>>
>> So, I don't want to make debate here of wether centralized is better tha=
n
>> distributed (because the point is moot), but I think its not a good
>> situation for the community to have a previously open door to DVCSs now
>> closed.
>>
>> Perhaps a solution can be found to even open the door to Mercurial (that
>> is
>> an excellent place to start with DVCSs because its simplicity and
>> straight-forwardness) in addition to git in such a way that doesn't stre=
ss
>> the server?.
>>
>> Regards,
>>
>> David
>>
>> On Wed, Apr 27, 2011 at 9:40 PM, Drak<drak@zikula.org>  wrote:
>>
>>  On 28 April 2011 07:55, Ben Schmidt<mail_ben_schmidt@yahoo.com.au>
>>>  wrote:
>>>
>>>  I realise that at least for now, PHP is sticking with SVN. No problems=
.
>>>>
>>>>
>>> I realise this is not the topic of discussion but I have to say, that
>>> overall, a switch to DVCS would make a huge difference to PHP developme=
nt
>>> life cycles.  Git for one, makes contributing and integration of patche=
s
>>> a
>>> completely different experience.  It encourages more community
>>> participation
>>> without impinging on quality since you don't need to grant commit
>>> permissions.  The whole workflow of creating and integrating patches is
>>> much
>>> faster and more simple because you can switch context from branch to
>>> branch
>>> almost instantly allowing those with commit permissions to verify if a
>>> contribution is worth merging or not.  It's much less work than SVN and
>>> the
>>> ease naturally attracts contributors.  Merging is not a pita like with
>>> SVN.
>>>
>>> However, given the recent security breach there is another side:
>>> Tampering
>>> with a git repository is virtually impossible because every commit hash
>>> is
>>> generated from the previous ones, so if your servers were compromised
>>> again,
>>> a change in the past history would require alteration every single comm=
it
>>> hash since that change and the resulting HEAD hash would be different.
>>>  Since hashes are  based on the commit contents it's just not feasible
>>> even
>>> if SHA1 was one day compromised that you could successfully tamper with=
 a
>>> previous commit and engineer the calculations so the current HEAD hash
>>> remained unchanged.  If a commit blob (on the file-system) was altered
>>> manually, your git repo would simply fail to validate the next time you
>>> use
>>> it. In every scenario you'd know immediately something was wrong and no=
t
>>> have to go looking for it commit by commit.
>>>
>>> Something to consider again in the future at least.
>>>
>>> Regards,
>>>
>>> Drak
>>>
>>>
>>

--0016e68e80269e096804a1f305e8--