[Vm-dev] a Cog branch

laurent laffont laurent.laffont at gmail.com
Fri Jun 25 08:39:00 UTC 2010


On Fri, Jun 25, 2010 at 10:09 AM, Andreas Raab <andreas.raab at gmx.de> wrote:

>
> On 6/25/2010 1:05 AM, Geoffroy Couprie wrote:
>
>>
>> On Fri, Jun 25, 2010 at 9:53 AM, Andreas Raab<andreas.raab at gmx.de>
>>  wrote:
>>
>>>
>>> On 6/24/2010 7:16 PM, Igor Stasenko wrote:
>>>
>>>>
>>>> One user could create a project, then others may create forks or
>>>> subforks of his project(s)
>>>>
>>>
>>> How exactly is this a good thing? I don't want 200 forked Squeak VM
>>> versions; I want one canonical source that people can build from.
>>>
>>>
>> Forks can be really useful for people who have to maintain a set of
>> patches that may not be accepted in the repository (applications
>> requiring a specific VM configuration, servers, etc).
>>
>
> Do we have this problem? What patches do you or anyone else have that can
> or should not be integrated in the main source?
>

While I was trying to build squeak vm for Pharo with FT2Plugin I had to
maintain 3 patches long before they were integrated in squeak vm trunk.

With a DVCS it's easier to make collaborative experimentations, try new
things, merge the good ones, see popular patches.

That doesn't mean there's no official branch anymore.

Cheers,

Laurent

>
> Cheers,
>  - Andreas
>
>
>  With the
>> branching workflows in DVCS, you can still get updates from the main
>> repository, develop new features in parallel, and maintain your
>> patches without impacting the rest of the developers.
>>
>> With SVN, if you don't have commit access, you only have two
>> possibilities: store a lot of patches, and reapply them by hand at
>> each update, or use a dirty trick like git-svn. I'm using git-svn
>> right now: it is great to be able to commit locally, but it's a bit
>> heavy to use.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100625/f16bc8cf/attachment.htm


More information about the Vm-dev mailing list