Hi Chris,
On Mon, Feb 18, 2019 at 10:53 AM Chris Muller asqueaker@gmail.com wrote:
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:
- create a layer on top of FileSystem which works like FileDirectory,
then release it and deprecate it. :)
That's backwards. FileDirectory is the smaller, faster, lower-level, more-utilitarian framework. FileSystem is a "boutique" domain and framework with powerful high-level capabilities, but suffers from a performance-killing design issue. So it'd probably make more sense for FileSystem use FileDirectory as its "primitive", and then we can simply keep FileDirectory around as-is for legacy apps.
I disagree. FIleDirectory is an obsolete mess. FileSystem is a well designed, modern alternative, designed by a Squeaker (Colin). I would much rather see FileSystem as the foundation.
- add FileSystem to the Trunk and gradually migrate all uses of
FileDirectory to it.
This would be asking virtually every app to do a similar migration. All because of Squot?
Port Squot to use FileDirectory.
Don't port anything. Side-by-side existence. People who need
Squot simply load Filesystem too.
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@caesar.elte.hu>:
On Mon, 18 Feb 2019, Jakob Reschke wrote: > Am Mo., 18. Feb. 2019, 01:39 hat Levente Uzonyi <
leves@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 > >