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 —Brian Fitzpatrick and Ben Collins-Sussman— have acknowledged
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 =):


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

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?.



On Wed, Apr 27, 2011 at 9:40 PM, Drak <d...@zikula.org> wrote:

> On 28 April 2011 07:55, Ben Schmidt <mail_ben_schm...@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

Reply via email to