Re: DVCS

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 —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 =): http://programmers.stackexchange.com/questions/35074/im-a-subversion-geek-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 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 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 >