[Vm-dev] VMMaker branching

David T. Lewis lewis at mail.msen.com
Wed Mar 23 00:06:42 UTC 2011


On Tue, Mar 22, 2011 at 11:01:04PM +0100, Igor Stasenko wrote:
>  
> On 22 March 2011 22:30, 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?
> >
> > - Are you comfortable working with two repositories as opposed to
> > keeping both branches in one repository as currently set up?
> >
> > 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, one of the problems with having distributed branches that
> history is not so easily accessible
> (to check delta between two packages if they are in different
> repositories will be tedious task).
> I personally don't feel a need to do that right now.

OK

> We should really
> look why committing VMMaker package
> to SqS takes so much time.
> To my impression there is something wrong with uploading mechanism,
> because it should just transfer the file, save it on disk, close a
> connection and only then start various processing
> like send mails or computing diffs.

Yes, something certainly seems wrong there. I don't know if it
is associated with the commit notifications, or just something
generally flakey with the upload mechanism.

Dave



More information about the Vm-dev mailing list