[Vm-dev] a Cog branch

[Frank Shearar]

On 2010/06/25 11:18, Bert Freudenberg wrote:
>
> 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.

I use both hg and git, in the guise of TortoiseHg and TortoiseGit. Both 
please me.

I'm mildly more in favour of git. (1) TortoiseHg's UI doesn't look much 
like a native Windows app and fails to give you feedback that it's 
actually done something. (2) It's nice and easy to set up a shared 
account for serving up multiple repositories on your own machine for git 
- you just need SSH. With hg you have to install a web server and play 
around with hgwebdir.cgi. (In my probably limited experience: feel free 
to correct me!)

My main issue with both git and hg is a non-issue here: it's annoying to 
_share_ repositories on a Windows machine (but hg does have a built-in 
web server for ad-hoc sharing of single repositories).

I tried bzr (TortoiseBzr) year before last, or maybe early last year. 
Hopefully it has vastly improved in stability - loads of functionality 
was either stubbed out in the UI, or blew up.

frank