Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52035
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.160.42 cause and error)
Message-ID: <4DB8D647.4020709@lerdorf.com>
Date: Wed, 27 Apr 2011 19:51:51 -0700
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: Drak <drak@zikula.org>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <4DB8CCA9.7040604@yahoo.com.au> <BANLkTik+wffarxWj-hzm_uHf2b70dUb_jw@mail.gmail.com>
In-Reply-To: <BANLkTik+wffarxWj-hzm_uHf2b70dUb_jw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] DVCS
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On 04/27/2011 07:40 PM, Drak 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 development
> life cycles.  Git for one, makes contributing and integration of patches 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 commit
> 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 not
> have to go looking for it commit by commit.
>
> Something to consider again in the future at least.

Verifying the svn repository was the least painful part of that experience.

-Rasmus