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

Tudor Girba tudor at tudorgirba.com
Mon Mar 4 14:23:35 UTC 2019


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







More information about the Vm-dev mailing list