[Vm-dev] a Cog branch
keith_hodges at yahoo.co.uk
Sat Jun 26 03:28:42 UTC 2010
> 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
>> 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?
> - 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
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
More information about the Vm-dev