[Vm-dev] a Cog branch

Bert Freudenberg bert at freudenbergs.de
Fri Jun 25 09:18:19 UTC 2010


On 25.06.2010, at 10:39, Andreas Raab wrote:

> On 6/25/2010 1:23 AM, Geoffroy Couprie wrote:
>>> Do we have this problem? What patches do you or anyone else have that can or
>>> should not be integrated in the main source?
>> 
>> I have my CMake patches (to be able to build the Windows VM with
>> CMake), and some patches to build the Windows VM with GCC. I sent the
>> patches here 2 months ago (you never answered on that thread), and
>> although people seemed interested by that code, it was never added in
>> the repository. I had to store the CMake patches, and then the other
>> Windows patches, and working on these different pieces of code without
>> being able to commit was painful.
> 
> Sorry about this, I've been quite busy with other things (such as the Cog release). The patches itself sound quite reasonable to me and probably should be integrated, no?
> 
> BTW, I don't think you've ever asked for commit rights. Regarding cmake, I have no problems giving you access so that you can keep the cmake stuff current.
> 
>> I also modify the VM for self education/fun purposes, and these
>> modifications would never be accepted in the main tree (heavily
>> breaking large parts of the memory allocations, weird plugins, etc).
> 
> But those patches then are just as unlikely to apply to other large changes in the main VM sources. That's a bit my point here. We've basically got two options:
> 
> 1) Everyone forks in their own little worlds, creating chaos. We've had that in the past, it did not work AT ALL.
> 
> 2) We try to be reasonable and integrate things back into the main sources. Give people who do active development commit rights for the relevant portions. Stay reasoable all along.
> 
> I'm *strongly* in favor of the latter.
> 
> Cheers,
>  - Andreas

Maybe you have not developed using a distributed versioning system yet? A DCVS would be for the VM what the trunk process is for the Squeak image. There still would be a "mainline" which is the official source tree. But people could work independently on their changes, and it's really simple to fold changes back, much simpler than in svn.

The reason 1) above did not work is because there was no way to track the changes and fold them back. Maybe read "the forking non-problem" here:
http://hgbook.red-bean.com/read/how-did-we-get-here.html

A DCVS allows precisely that tracking and fold-back. You could develop in private, but in practice having a shared repository for all private trees works well. E.g., look at the Sugar repository:

http://git.sugarlabs.org/projects/sugar

There is a "mainline" which several people have commit access to, constituting the official sources. But there are also any number of clones for people's experiments. It's really simple to switch your working copy to one of these personal trees, to test something, and switch back. 

The thing is that there is zero barrier to entry - anyone can clone the official tree and start hacking. It's like the inbox.

So I'm strongly in favor of switching to a DCVS. I personally only ever used git, but since hg supposedly has better x-platform support that would be fine too (the Windows devs should speak up). Wouldn't be opposed to bzr either. 

- Bert -



More information about the Vm-dev mailing list