<br><br><div class="gmail_quote">On Tue, Mar 22, 2011 at 2:30 PM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
On Sun, Mar 20, 2011 at 12:43:39PM +0100, Igor Stasenko wrote:<br>
><br>
> On 20 March 2011 12:37, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>
> ><br>
> > On 19.03.2011, at 19:48, Igor Stasenko wrote:<br>
> >><br>
> >> On 19 March 2011 19:44, Matthew Fulmer <<a href="mailto:tapplek@gmail.com">tapplek@gmail.com</a>> wrote:<br>
> >>><br>
> >>> On Sat, Mar 19, 2011 at 01:36:04PM -0400, David T. Lewis wrote:<br>
> >>>> I have stayed away from committing anything directly to the oscog<br>
> >>>> branch out of concern that it may lead to confusion between the<br>
> >>>> two branches if my 'dtl' initials start showing up there. I do<br>
> >>>> have some changes that can be applied to oscog (mostly to get<br>
> >>>> rid of cosmetic differences between the two branches that clutter<br>
> >>>> up the Montecello browser). I've sent a few of these to Eliot but<br>
> >>>> I don't know if that is the preferred approach going forward.<br>
> >>>> Advice welcome, as I do want to put some more effort into reconciling<br>
> >>>> the code bases pretty soon.<br>
> >>><br>
> >>> MC supports branching, but lacks a built in way to mark the<br>
> >>> branches as seperate. We have 3 branches of Cobalt currently,<br>
> >>> and we keep them seperate by keeping them in seperate<br>
> >>> repositories.<br>
> >>><br>
> >><br>
> >> Well, i am actually used different naming for oscog branch<br>
> >> (VMMaker-<name>-oscog).<br>
> >> And MC lists it as a separate package.<br>
> ><br>
> > 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.<br>
> ><br>
><br>
> Yes, but i don't want it to be same, so its not lost in a list of<br>
> Squeak (non-Cog) VMMaker packages.<br>
><br>
<br>
</div></div>If multiple people are going to be committing to the oscog branch,<br>
then I think that Matthew is pointing us in a good direction. Just<br>
to try it out, I made a local repository on my own hard drive, and<br>
copied all of the cog MCZs into it from SqueakSource. It is simple<br>
(though a bit tedious) to set up a repository like this on SqueakSource<br>
such that we would have two companion VMMaker repositories while<br>
working through the code merge. It does look to me like it this<br>
organization would make it easier to keep track of things, and I<br>
will be happy to set it up if you (Eliot and Igor especially) agree<br>
it is the right thing to do.<br>
<br>
So let me ask a couple of questions:<br>
<br>
- Eliot, are you happy to have other people commit MCZ updates for<br>
the oscog branch? In particular, is it OK if I do that?<br></blockquote><div><br></div><div>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?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
- Are you comfortable working with two repositories as opposed to<br>
keeping both branches in one repository as currently set up?<br></blockquote><div><br></div><div>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 <a href="http://www.squeaksource.com/VMMaker">www.squeaksource.com/VMMaker</a>.</div>
<div><br></div><div>But then I may be missing something.</div><div><br></div><div>BTW, I /so/ agree with Igor that "w<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">e should really </span><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">look why committing VMMaker package </span><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">to SqS takes so much time". It's agony :)</span></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br></span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">best,</span></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Eliot</span></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
If yes to both, then I will volunteer to set up the SqueakSource<br>
project to do this. After it is set up, we can turn on email commit<br>
notifications so that it will work exactly like the current VMMaker<br>
project. Assuming that we successfully accomplish the merge, we<br>
can move things back into one repository at a later date.<br>
<br>
Dave<br>
<br>
<br>
</blockquote></div><br>