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

[Jakob Reschke]

Hi,

Am Mo., 4. März 2019 um 15:24 Uhr schrieb Tudor Girba <tudor at tudorgirba.com
>:

>
> 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?
>

At the moment, it is only FileTree, but the Tonel adapter is in the works.
No, I have not used Squot on a project as large as VMMaker. Squot itself is
probably medium-sized and is the largest project I use it on. I have also
not used the Monticello converter on a larger history than that of
FileSystem-Git and FileSystem for Squeak (their numbers were less than a
tenth of those on VMMaker). The converter is probably slower than
git-migration because it uses neither git-fast-import, nor libgit2. Since
the history conversion is a seldom task, I did not bother to make it as
quick as possible. I might try to convert the VMMaker ancestry to see how
it goes and how long it takes. But since I have no personal projects in
VMMaker, I would only evaluate how the conversion went and nothing more.


>
> 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.
>

It is good enough to continue working on the present state of a project,
sure. But it will incite angriness if someone inspects the history (someone
will do it) and runs into problems like Nicolas did. Once you have chosen
to lose something (accurate ancestry) during the conversion, you won't be
able to get it back so easily in the future. Moreover, you cannot easily
rewrite the Git history again after you have shared it (in case you might
change your mind and want to fix up the ancestry later). That's why I would
be very cautious and advise against being satisfied with just "good
enough". The Squot converter is not perfect in that regard either, as it
currently loses the Monticello version names and UUIDs. Maybe I should
better put these at the bottom of the commit messages.

Missing versions are a nuisance, too. But unless you know where to find
them...

Best,
Jakob


>
> > 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/cbe964d6/attachment-0001.html>