[Vm-dev] VMMaker branching

[Eliot Miranda]

On Tue, Mar 22, 2011 at 2:30 PM, David T. Lewis <lewis at mail.msen.com> wrote:

>
> On Sun, Mar 20, 2011 at 12:43:39PM +0100, Igor Stasenko wrote:
> >
> > On 20 March 2011 12:37, Bert Freudenberg <bert at freudenbergs.de> wrote:
> > >
> > > On 19.03.2011, at 19:48, Igor Stasenko wrote:
> > >>
> > >> On 19 March 2011 19:44, Matthew Fulmer <tapplek at gmail.com> wrote:
> > >>>
> > >>> On Sat, Mar 19, 2011 at 01:36:04PM -0400, David T. Lewis wrote:
> > >>>> I have stayed away from committing anything directly to the oscog
> > >>>> branch out of concern that it may lead to confusion between the
> > >>>> two branches if my 'dtl' initials start showing up there. I do
> > >>>> have some changes that can be applied to oscog (mostly to get
> > >>>> rid of cosmetic differences between the two branches that clutter
> > >>>> up the Montecello browser). I've sent a few of these to Eliot but
> > >>>> I don't know if that is the preferred approach going forward.
> > >>>> Advice welcome, as I do want to put some more effort into
> reconciling
> > >>>> the code bases pretty soon.
> > >>>
> > >>> MC supports branching, but lacks a built in way to mark the
> > >>> branches as seperate. We have 3 branches of Cobalt currently,
> > >>> and we keep them seperate by keeping them in seperate
> > >>> repositories.
> > >>>
> > >>
> > >> Well, i am actually used different naming for oscog branch
> > >> (VMMaker-<name>-oscog).
> > >> And MC lists it as a separate package.
> > >
> > > Because the MC UI treats everything up to the last hyphen as package
> name (it does not look inside for the actual package name). If you named it
> e.g. VMMaker-<name>_oscog then it would be listed as the same package.
> > >
> >
> > Yes, but i don't want it to be same, so its not lost in a list of
> > Squeak (non-Cog) VMMaker packages.
> >
>
> If multiple people are going to be committing to the oscog branch,
> then I think that Matthew is pointing us in a good direction. Just
> to try it out, I made a local repository on my own hard drive, and
> copied all of the cog MCZs into it from SqueakSource. It is simple
> (though a bit tedious) to set up a repository like this on SqueakSource
> such that we would have two companion VMMaker repositories while
> working through the code merge. It does look to me like it this
> organization would make it easier to keep track of things, and I
> will be happy to set it up if you (Eliot and Igor especially) agree
> it is the right thing to do.
>
> So let me ask a couple of questions:
>
> - Eliot, are you happy to have other people commit MCZ updates for
> the oscog branch? In particular, is it OK if I do that?
>

At the moment I'm a little uncomfortable with this.  I think its still a few
weeks too early.  VMMaker-oscog.N is my reviewed/approved line of Cog
sources.  Once I'm using INRIA-Lille's Hudson server to do builds and have
tests green etc I'll be happy either to allow  VMMaker-oscog.N to be used by
everybody, or to see it die and folded into VMMaker-whoever.N.  Until then
would you mind following Igor's convention, e.g. VMMaker-oscog-dtl.N?


> - Are you comfortable working with two repositories as opposed to
> keeping both branches in one repository as currently set up?
>

Doesn't seem to me to make sense.  We've agreed that the right arc is to
refactor Interpreter out from under ObjectMemory in which case we're clearly
heading to merge to one VMMaker containing 4 or more VMs (context and stack
interpreters, Cog and CogMT jits, with possibly/hopefully someone doing a
StackMT).  Splitting the VMMaker repository seems to be going against this
direction.  Nothing stops people form committing a VMMaker wherever they
choose but in our main-line work I don't think we want to be using other
than www.squeaksource.com/VMMaker.

But then I may be missing something.

BTW, I /so/ agree with Igor that "we should really look why committing
VMMaker package to SqS takes so much time".  It's agony :)

best,
Eliot


> If yes to both, then I will volunteer to set up the SqueakSource
> project to do this. After it is set up, we can turn on email commit
> notifications so that it will work exactly like the current VMMaker
> project. Assuming that we successfully accomplish the merge, we
> can move things back into one repository at a later date.
>
> Dave
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110324/2840f8ce/attachment.htm