Forks (Re: [Vm-dev] a Cog branch)

[Andreas Raab]

On 6/25/2010 1:41 AM, Casey Ransberger wrote:
> So I guess what I'm saying is that I think we shouldn't worry at all about forks, and that statement includes not worrying at all about being compatible with forks. If I wanted to fork Squeak (and I do from time to time,) quite frankly, I think it would be unreasonable to expect Squeak to be compatible with my fork; when you fork, you're on your own. Anyone who's ever maintained a fork of something knows this from personal experience.
>
> Now back to SCM. There are some nice wins with Git over Subversion, mostly to do with fast merges and distributed development. In fact I'd like it if we learned some things from Git in our further development of Monticello.

I agree with merging (the only argument that carries any weight here). I 
don't buy the forking argument. The number of people building VMs is 
*tiny* compared to general Squeak users. Having those fork instead of 
pool their resources is an absolutely deadly fallacy. As a consequence, 
I think that it's a Very Good Thing (tm) having to pay a price for 
forking. It should be easier to contribute back to main line sources 
than to fork.

> But for the love of God, can we keep Cog in the same repository that we keep the rest of the Squeak VMs? Maybe we switch to Git or Mercurial for managing C sources eventually, but we should do it across the board. Squeak is (from the moment they decided to actually use the Blue Book sources as a starting point) a *reference implementation.* You really don't want more than one of those.

Absolutely. Eliot's initial point was exactly that, i.e., decouple the 
discussion about a change in SCM from having a Cog branch. I don't think 
anyone is arguing that point.

> I'm going to pull a total Jack-move and call Godwin's Law on myself in a shameless attempt to kill this subject as quickly as possible: Hitler.

:-)

Cheers,
   - Andreas