Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52034
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zikula.org designates 74.125.82.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4DB8CCA9.7040604@yahoo.com.au>
References: <4DB8CCA9.7040604@yahoo.com.au>
Date: Thu, 28 Apr 2011 08:25:58 +0545
Message-ID: <BANLkTik+wffarxWj-hzm_uHf2b70dUb_jw@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=0016e6dd8a66e39bca04a1f17da0
Subject: Re: [PHP-DEV] DVCS
From: drak@zikula.org (Drak)

--0016e6dd8a66e39bca04a1f17da0
Content-Type: text/plain; charset=UTF-8

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.

Regards,

Drak

--0016e6dd8a66e39bca04a1f17da0--