Darren Duncan wrote:
1. Git makes it very safe for any number of contributors to push work
to the same repository. Since commits are not all sequential, like in
svn, and they are identified just by hashes of the actual data being
committed plus the change history of said data, contributors can push
commits in any order and will not step on each other. Everyone can work
on their own things, and they don't have to worry about immediately
merging everyone else's changes in order to share their own.
But you haven't explained how that is useful to developing _Perl_. When
I develop something in the core, I don't want my own version of the core
code. I want to have *exactly* the same as everyone else, except for my
changes, so that I can be sure that my changes do not cause problems in
the core before I submit it.
3. At the same time, each user maintains control over what they see
themselves; merges are always pulled by each user, not pushed by
others. So while people can experiment, and anyone can do releases of
their POV, we can still have authorities that maintain central branches,
that just pull-merge the good commits as they vet them, into what
becomes the official distros. But people don't need vetted changes in
order to get them backed up in the system and shared/seen by others.
Again, I completely miss the benefit for a project like Perl for
everyone writing code for the core to have their own "version" of Perl.
No one is going to release a branch of Perl based on their own merge,
and I'm not even sure that anyone would apply someone else's work before
it was vetted. So how is that a benefit and not a huge drawback?

The Perl5 core (and by this I largely mean the C code, not the PM files)
is not a collection of largely independent modules. It has been
accurately described as programming Jenga-style (Perl6 is down the hall
on the right). It is relatively rare that a large new feature won't
affect other existing features in sometimes rather subtle ways (see the
regular BBC emails). Having 100 people with very slightly different
local repositories doesn't strike me as a good thing. And if you just
say that they should always pull the vetted patches, you've just neatly
removed any benefit gained by using a "distributed" VCS at all.

A lot of people that say "we need a distributed VCS" really should be
saying "we need a disconnected VCS". This is a related concept, but by
no means the same thing. As long as I can have a local branch for my
own development, then push that branch (with all of it's hemming and
hawing if I so choose) to a central repository is everything *I* need.

It's really nice to have a local mirror (so when the 2.4GHz cordless
phone messes up my WIFI, I can still be working), but I'd what *I'd*
really like to have a depth 1 mirror (i.e. only the current trunk at any
time). I would like to keep that mirror up to date quickly and easily,
and merge down changes to my local branches automatically (as much as
that is possible). There isn't a single VCS that will do that for me


John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2019 Grokbase