Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52036
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 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=LGVjoFMPi6WyXeJraq0Vji7n454EjHuFIYTCTTFjTjQZJaBDmNTfejC8j8Beu20p+e
         azW9wdoLCV1rW/OoGRVthe4KMEsrbcQEgWFdvBCYA8LajmpiscIHNxg6I0BL8HRkgjXq
         tIIXMuvaRS+KaKngS+oVyU0M86rVX+SBzfZSA=
MIME-Version: 1.0
In-Reply-To: <BANLkTik+wffarxWj-hzm_uHf2b70dUb_jw@mail.gmail.com>
References: <4DB8CCA9.7040604@yahoo.com.au> <BANLkTik+wffarxWj-hzm_uHf2b70dUb_jw@mail.gmail.com>
Date: Wed, 27 Apr 2011 22:07:10 -0500
Message-ID: <BANLkTinZewZVgmNqzw_4tOs3ShmaxOcnrA@mail.gmail.com>
To: Drak <drak@zikula.org>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001636eee3dc99822704a1f1db16
Subject: Re: [PHP-DEV] DVCS
From: dukeofgaming@gmail.com (dukeofgaming)

--001636eee3dc99822704a1f1db16
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi,

I'm not a frequent poster in the list but I thought I'd really should give
my 1 cent here when I saw "popular" being an argument for using DVCSs, its
not, and its neither fashion nor cargo cult, it is just a plain eye opener
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 acknowled=
ged
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 th=
e
one I've already made, diagrams and graphics included =3D):

http://programmers.stackexchange.com/questions/35074/im-a-subversion-geek-w=
hy-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 than
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 stress
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 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 bran=
ch
> 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 t=
he
> ease naturally attracts contributors.  Merging is not a pita like with SV=
N.
>
> However, given the recent security breach there is another side: Tamperin=
g
> with a git repository is virtually impossible because every commit hash i=
s
> 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 ev=
en
> 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 u=
se
> 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
>

--001636eee3dc99822704a1f1db16--