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.

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

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

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.

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
>
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190218/5741ed38/attachment.html>