[Vm-dev] a Cog branch

[keith]

> On 6/25/2010 4:29 PM, Douglas Brebner wrote:
>> I think the problem is with the use of the word "fork". Isn't a  
>> private
>> copy of a repo more akin to a branch?
>
> Well, if that's the case, how about addressing it by using branches?  
> Right here on squeakvm.org? Would this alleviate your perceived need  
> to fork?
>
> Cheers,
>  - Andreas


This point may not be as relevant to the vm discussion as it might be,  
but I am not subscribed to the squeak-dev list.

When you decide that forks are not desirable, you force everyone else  
who doesn't happen to be tracking you on a daily basis, to fork by  
default. Git/bzr provides a default way of working where you pull  
working stuff from working forks aka branches. The result, forking  
works for you, not against you, because you have the tools and the  
process surrounding the tools which is not afraid of forking.

In git/bzr etc all forks are branches, with common tools for interop  
between the branches. In squeakland it is different, a fork is a hard- 
fork, because the tools (MC,sunit) are not common between forks.

Stephane created pharo, and in one day effectively made half of my  
code base into a fork of pharo, that was difficult to support, and had  
no way of contributing back into pharo, because pharo's code  
management tools, and testing tools were different to mine.

Andreas created "trunk", and in one day made the other half of my  
entire code base into a fork of Squeak, in exactly the same way.

The position of "not desiring forks" is basically unsupportable,  
because blatantly we have several official forks and hundreds of other  
images "left behind", with packages in squeaksource for every variant  
in between.

This is not as painful in other languages, because basically all they  
need in the way of common tools is a text editor.

In smalltalk, everything moves so fast, once you get to a situation  
where you are building your stuff on top of other people's stuff, and  
they are moving their projects forward, you need some coherent  
strategy to cope, or the whole thing collapses very quickly.

Neither Andreas, nor Stephane appear to be familiar with this problem,  
perhaps they never build anything on top of other peoples code that  
they are not in complete control of.

I have a solution for working across forks, my solution uses bzr/ 
launchpad for scm, and provides much simpler common tools for all  
forks, and potentially all smalltalks. (no MC in sight). Using my  
solution I can create and maintain a package in all forks  
simultaneously, because I have developed a tool set that is designed  
knowing that I do not have control over what anyone does or what  
facilities an image will have in it.

I am unsubscribing shortly

regards

Keith