Hi Chris,

On Mon, Feb 18, 2019 at 10:53 AM Chris Muller <asqueaker at 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:
> > 1. 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.


>
> > 2. 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?
>
> 3.  Port Squot to use FileDirectory.
>
> 4.  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 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
> > >
> > >       >
> > >       >
> > >
> > >
> > >
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190218/aa6040fb/attachment.html>