[Vm-dev] I'll come in again...

[John Dougan]

Maybe some external input would help here:

http://www.joelonsoftware.com/items/2010/03/17.html
http://redmonk.com/sogrady/2010/04/01/github/
http://utsl.gen.nz/talks/git-svn/intro.html

"Distributed version control software is not incompatible with communal,
centralized development. In practice, most projects that use distributed
software still have one central repository that everyone syncs and submits
to. They're not using the distributed software to split development off into
isolated forks; they're using it precisely to allow work to be shared more
easily without such hard boundaries between established developers and new
contributors."
 #<http://blog.ianbicking.org/distributed-vs-centralized-scm-comment-13.html>
Matt
Brubeck <http://advogato.org/person/mbrubeck/>

It's hard to explain the benefits, but perhaps I can show drawbacks.
Monticello is a DVCS (albeit the simplest one imaginable and desperately
needing better tool support). What would it Squeak development be like if we
had no choice but to sync to the one SqueakSource rather then our own local
package caches and network repositories? How would this change the ease of
making contributions, trying complex experiments, managing the repository,
working offline, etc.

Cheers,
  -- John

On Sun, Jun 27, 2010 at 13:06, Igor Stasenko <siguctua at gmail.com> wrote:

>
> On 27 June 2010 22:02, Andreas Raab <andreas.raab at gmx.de> wrote:
> >
> > Folks -
> >
> > I feel like I've been thoroughly misunderstood in the recent discussion
> > about using a distributed version control system. Let me try to make my
> > point as clearly as possible:
> >
> > First of all I don't *care* whether to use a "distributed" VCS or not. Is
> > that clear? I really don't. What I care about for a version control
> system
> > is how easy it is to use and how well it integrates with the system I
> use.
> >
> > Having been clear on the initial point, my concern in this discussion is
> > about *why* people seem to be excited about using an DVCS. What I'm
> hearing
> > is "great, now we can fork" instead of "great, this will make it easier
> to
> > contribute".
> >
> > There is a difference between a "branch" and a "fork". A "branch" is
> > something where you (usually temporarily) diverge from the main line in
> > order to make the original product better. A "fork" is a (usually
> permanent)
> > divergence from the main line WITHOUT the intention to make the original
> > product better. For example, Cog is a branch, Pharo is a fork.
> >
> > Branches are *great*. Branches allow us to explore directions without
> > destabilizing the main development. Forks are *terrible*. Forks split
> > communities, force duplication of efforts, and split mindshare that would
> > better be spent on making the system better for everyone.
> >
> > As a consequence, when I hear people being excited about the ability to
> > "fork" I am starting to ask myself what we can do to avoid the need for
> > forks. Forks don't just happen - there are events that lead up to it and
> I
> > am trying to understand if there's something we can do to alleviate the
> > perceived need for forking.
> >
> > I'm not trying to tell you that you *must* host your private experiments
> on
> > Squeak.org - I am asking to find out what kind of frustration exist in
> our
> > current development process, and what we can do to address them.
> >
>
>

-- 
John Dougan
jdougan at acm.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100627/4fd50cf5/attachment.htm