On Mon, 18 Feb 2019, Jakob Reschke wrote:

> Yes, it is feasible like that, but not ideal. Not all of these packages are changed with every commit, so you would generate multiple consecutive MCVersions of a package with the unchanged contents in
> comparison to their immediate ancestor and a log message that does not pertain to the package at all.

Well, that's just the question of writing the tool. It could easily detect 
that some commit doesn't modify package X, so there's no need to create a 
new version of it.

> Since Squot has already solved this once, the fundamental question is how much effort someone wants to invest to backport features to Monticello and whether the effort is desired and warranted. I've

That is indeed a question. It seemed to me that even if just temporarily, 
having .mcz versions would solve Eliot's problem.

> heard multiple voices that do not want to go back to Monticello. And I'm sure there are at least as many on the list that do not want to let it go. ;-) Side note: Squot uses the Monticello model for
> packages (i. e., MCSnapshot and MCPatch and their contents, and the loader facilities), but it does not use MCVersion or MCRepository.

MC is far from perfect. It's a "quick hack". It doesn't scale well. And 
there were bad design decisions made. But it still works, and many 
toolchains rely on it, e.g. the Trunk or VMMaker.

> 
> In any case, you would need something to access the Git history and object database. In Pharo this is the libgit2 binding. In Squot it is FileSystem-Git, which could also be reused to write something

What I had in my mind was a lot simpler: watch a repository for new 
commits. When a new commit appears, fetch it, load the tonel code into an 
image and create the new .mczs. Store the new .mczs in a repository. 
Repeat.

> for Monticello. But since it is coupled with FileSystem, the next discussion will be whether that should finally be adopted into Trunk, and if so in which form. Again, I've heard multiple proponents
> to make this move.

I'm fine with moving to FileSystem, provided it is ready for production. 
I see two possible ways to achieve that:
1. create a layer on top of FileSystem which works like FileDirectory, 
then release it and deprecate it. :)
2. add FileSystem to the Trunk and gradually migrate all uses of 
FileDirectory to it.

> After that, the next problem will be that the current MCRepository hierarchy couples file formats and ancestry storage. In the case of Monticello-in-another-VCS, these are orthogonal: you can have
> FileTree layouts in Git, you can have Tonel layouts in Git, you could have both at the same time, you could have both in a different VCS in the future... So instead of a "FileTree"-Repository and a
> "Tonel"-Repository, I think there should rather be a "Git"-Repository that picks the correct readers and writers dynamically to process the files and directories in each commit. To make the smell more
> tangible: I think neither MCFileTreeRepository (or whathever its name actually is) nor TonelRepository should be subclasses of MCFileBasedRepository (they are today), although it sounds crazy.

I don't think it is a good idea to mix MC and git at all. IMO we only 
need tools to safely and reliably migrate from one to the other to start a 
change.

Levente

> 
> Am Mo., 18. Feb. 2019 um 11:45 Uhr schrieb Levente Uzonyi <leves at caesar.elte.hu>:
>       On Mon, 18 Feb 2019, Jakob Reschke wrote:
>
>       > Am Mo., 18. Feb. 2019, 01:39 hat Levente Uzonyi <leves at caesar.elte.hu> geschrieben:
>       >
>       >       Is it a must to use Metacello to load code in Tonel format?
>       >       What does Metacello add to the mix?
>       >       Can't we just map each git commit to an mcz?
>       >
>       >       Levente
>       >
>       >
>       > Strictly speaking, Metacello is not required. But you would have to resolve the package dependencies yourself and gather them from external repositories, which is the main benefit of
>       Metacello. So I
>       > understand that Eliot wants it to work.
>       >
>       > There is no mcz to map to. If one were to create a new kind of MCRepository that maps commits to MCVersions, you would have 0..* MCVersions per commit because each commit may touch
>       multiple packages
>       > or none. Each commit describes a particular configuration of package versions, so one could generate an artificial MCConfiguration for each commit. Note that Squot / the Git Browser
>       already supports
>       > these scenarios for FileTree repositories, albeit without using Monticello for the version control.
>
>       Looking at the repository in question[1], there seem to be multiple
>       packages stored in it[2]: BaselineOfScorch, Scorching, ScorchingDev,
>       ScorchingTests, ScorchingVMTests. My impression is that these could be
>       converted to individual mczs for each commit, which would mean that the
>       same code would be available as MC packages. Then you could load the code
>       with MC/Metacello/whatever from the .mczs.
>
>       Am I missing something?
>
>       Levente
>
>       [1] https://github.com/clementbera/Scorch
>       [2] https://github.com/clementbera/Scorch/tree/master/repository
>
>       >
>       >
> 
> 
>