Maybe some external input would help here:<br><br><a href="http://www.joelonsoftware.com/items/2010/03/17.html">http://www.joelonsoftware.com/items/2010/03/17.html</a><br><a href="http://redmonk.com/sogrady/2010/04/01/github/">http://redmonk.com/sogrady/2010/04/01/github/</a><br>
<a href="http://utsl.gen.nz/talks/git-svn/intro.html">http://utsl.gen.nz/talks/git-svn/intro.html</a><br><br>"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."<div class="document">
</div>
<div align="right"><a href="http://blog.ianbicking.org/distributed-vs-centralized-scm-comment-13.html" rel="nofollow">#</a> <a href="http://advogato.org/person/mbrubeck/">Matt Brubeck</a></div><br>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. <br>
<br>Cheers,<br> -- John<br><br><div class="gmail_quote">On Sun, Jun 27, 2010 at 13:06, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5"><br>
On 27 June 2010 22:02, Andreas Raab <<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>> wrote:<br>
><br>
> Folks -<br>
><br>
> I feel like I've been thoroughly misunderstood in the recent discussion<br>
> about using a distributed version control system. Let me try to make my<br>
> point as clearly as possible:<br>
><br>
> First of all I don't *care* whether to use a "distributed" VCS or not. Is<br>
> that clear? I really don't. What I care about for a version control system<br>
> is how easy it is to use and how well it integrates with the system I use.<br>
><br>
> Having been clear on the initial point, my concern in this discussion is<br>
> about *why* people seem to be excited about using an DVCS. What I'm hearing<br>
> is "great, now we can fork" instead of "great, this will make it easier to<br>
> contribute".<br>
><br>
> There is a difference between a "branch" and a "fork". A "branch" is<br>
> something where you (usually temporarily) diverge from the main line in<br>
> order to make the original product better. A "fork" is a (usually permanent)<br>
> divergence from the main line WITHOUT the intention to make the original<br>
> product better. For example, Cog is a branch, Pharo is a fork.<br>
><br>
> Branches are *great*. Branches allow us to explore directions without<br>
> destabilizing the main development. Forks are *terrible*. Forks split<br>
> communities, force duplication of efforts, and split mindshare that would<br>
> better be spent on making the system better for everyone.<br>
><br>
> As a consequence, when I hear people being excited about the ability to<br>
> "fork" I am starting to ask myself what we can do to avoid the need for<br>
> forks. Forks don't just happen - there are events that lead up to it and I<br>
> am trying to understand if there's something we can do to alleviate the<br>
> perceived need for forking.<br>
><br>
> I'm not trying to tell you that you *must* host your private experiments on<br>
> Squeak.org - I am asking to find out what kind of frustration exist in our<br>
> current development process, and what we can do to address them.<br>
><br>
<br>
</div></div></blockquote></div><br clear="all"><br>-- <br>John Dougan<br><a href="mailto:jdougan@acm.org">jdougan@acm.org</a><br>