[Vm-dev] VMMaker in Pharo [Was: Squeak and Tonel]
forums.jakob at resfarm.de
Mon Mar 4 07:42:44 UTC 2019
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
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 (
<https://git-scm.com/docs/git-log#git-log---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
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:
>> 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:
> Normally I should see only one diff, like this:
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev