Just for the record....I didn't say popularity was a reason to use a DVCS. I said
the popularity of DVCSes might cause server strain (if a lot of people want to
convert the public SVN repo to a distributed one, downloading all the changes in
the repo, which SVN really wasn't designed for, that would be a heavy load--and
positively correlated to popularity: more popular, more conversions, more load).
I agree with your closing point, though: I'd love to see us look for a low-load
way of providing an Hg mirror and/or a Git mirror. I also think that either a
mirror or a change of VCS may attract developers in the medium-term. However, I
also think that current developers carry a lot more weight than potential
developers, and it's important for them to be able to work in a way that is
comfortable for them. So a mirror or two would be nice, and I'd push for that, but
a change of official repo I will merely suggest be considered longer term.
Ben.
On 28/04/11 1:07 PM, dukeofgaming wrote:
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<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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
