[Vm-dev] VMMaker in Pharo [Was: Squeak and Tonel]

[Nicolas Cellier]

Hi Tudor,
It depends good enough for what?
If i'm the author of a change that happens to be a mistake, then i want to
be able to exert my responsibility.
But i must first understand the context in which i took sone decisions, and
a broken history won't help.
Also linear history is breaking authorship, so maybe i won't even blame
myself... example:

Vm.branch1-eem.10 change method a
Vm.branch2-nice.10 change method b
Vm.merge.eem.11 => i'm the author of b changes

But

Vm.branch1-eem.10 change method a
Vm.branch2-nice.10 change method b
Vm.branch1-eem.11 change method c
Vm.merge.eem.12 => Eliot is attributed the authorship of b changes

That often happens with my own changes because Eliot is continuously
developing. So from my POV, it's not good enough... just unusable.

Le lun. 4 mars 2019 à 15:23, Tudor Girba <tudor at tudorgirba.com> a écrit :

>
> Hi,
>
> Thanks for this summary!
>
> Do you have experience of using Squot on a project of the size of VMMaker?
> Would you like to try to see how it works? And does it work for Tonel, or
> only for FileTree?
>
> In any case, I also believe that it is not unreasonable to merge things in
> one linear history (or even to discard parallel Monticello branches). Here
> is my reasoning: the way the whole history in Monticello is, to a good
> extent, via the author timestamp. This essentially provides one change. So,
> for all practical purposes, preserving the main linear history is good
> enough.
>
> Cheers,
> Doru
>
>
> > On Mar 4, 2019, at 8:42 AM, Jakob Reschke <forums.jakob at resfarm.de>
> wrote:
> >
> > I had a quick look at the git-migration code. From what I saw, it binds
> all packages together in a linear history. Though the versions are
> topologically sorted by the Monticello ancestry, this approach cannot
> preserve any branches, or parallel changes, as Nicolas noted. Thus, it
> produces wrong diffs. Though, it is perfectly adequate for most one-person
> projects or projects with a Subversion-like commit policy ("you must always
> merge newer versions before you save"). I guess that is the majority of
> Monticello projects.
> >
> > For the converter in Squot, I chose to write one strand of commits for
> each package, ending in a branch. The history on each strand maps the
> package's Monticello ancestry accurately (except that the diffs for missing
> versions are still missing). But it is not appealing to work with each
> package on a different branch, of course. Unless you have Monticello
> configurations, that's all the model provides, is it? You can still get an
> idea of the inter-package history by viewing the log sorted by author
> timestamps (--author-date-order), but you cannot really bisect it, for
> example.
> >
> > What I did in my repositories so far is import the packages on separate
> branches and then create an n-way merge (with the command line tools) that
> pulls all the packages together from the point on when I established the
> Git repository.
> >
> > Binding the packages together in a common history needs some kind of
> heuristic that guesses the past configurations that were in use. For
> example, timestamps and authors could be used. Let's say contributors abc
> and xyz worked on some project in parallel and created versions in multiple
> packages. Then you could assume that PkgX-abc.8 and PkgY-abc.42 with
> similar timestamps belong to the same branch, while PkgX-xyz.8 (with the
> same parent as PkgX-abc.8) and PkgZ-xyz.5 with similar timestamps belong to
> a different branch. There will most certainly be scenarios where the
> heuristic breaks. For example, when the change in PkgZ-xyz.5 is also
> relevant for abc's work and she "invisibly" adopts it on her "branch" in
> Monticello. Or when abc works on her branch and then must quickly fix a bug
> on whatever "master" in Monticello is, but modifies a different package
> there (so you cannot see the "switch" in the ancestry).
> >
> > So the one-nonlinear-branch-per-package approach is unwieldy, but at
> least it is does not produce incorrect results until someone comes up with
> a better solution. As written above, the git-migration approach is fine for
> one-person or branch-less projects.
> >
> > Am So., 3. März 2019 um 09:23 Uhr schrieb Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com>:
> >
> >
> >
> > Le dim. 24 févr. 2019 à 21:19, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> a écrit :
> > Hi Doru,
> >
> > Le mar. 19 févr. 2019 à 10:39, Tudor Girba <tudor at tudorgirba.com> a
> écrit :
> >
> > Hi Nicolas,
> >
> >
> > > On Feb 18, 2019, at 3:12 PM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
> >
> > > Also note that vmmaker history as proposed in opensmalltalk pr was
> broken (no respect of branch topology). Maybe retry with Squot?
> > > https://github.com/hpi-swa/Squot
> > > There is still a problem of synching commits of other packages (cog,
> various plugins ...), and if nobody is working on it, we are condemned to a
> mediocre solution.
> > > IMO, a broken history has not much interest.
> >
> > We know it was broken, and thank you for pointing it out. We went
> through multiple iterations, and we think the latest one should be better.
> Please take a look and let us know if you still find issues:
> > https://github.com/feenkcom/opensmalltalk-vm/tree/pullrequest5/vmmaker
> >
> >
> > Ah OK, I'll try to have a look.
> >
> >
> > Hi Doru,
> > as follow up, I don't see the progress in package history.
> > If I look for example at history of ThreadedFFIPlugin, then I see this:
> >
> >
> https://github.com/feenkcom/opensmalltalk-vm/commit/2ec3b0f6da1a5c7801f7ce8973213ba00b10d7fd#diff-36ccd126e0dd4f5ba2a399c962426080
> >
> > Normally I should see only one diff, like this:
> >
> > http://source.squeak.org/VMMaker/VMMaker.oscog-nice.2109.diff
> >
> > This is because true parent is VMMaker.oscog-eem.2108
> > But git parent is VMMaker.oscog-eem.2109
> > So it seems like I am undoing all the changes from Eliot... Thats is
> obscuring the intentions of the commit.
> >
>
> --
> www.feenk.com
>
> "What we can governs what we wish."
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190304/05f941f3/attachment.html>