<div dir="ltr"><div dir="ltr">Hi Chris,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 18, 2019 at 10:53 AM Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">> > 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<br>
><br>
> What I had in my mind was a lot simpler: watch a repository for new<br>
> commits. When a new commit appears, fetch it, load the tonel code into an<br>
> image and create the new .mczs. Store the new .mczs in a repository.<br>
> Repeat.<br>
><br>
> > 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<br>
> > to make this move.<br>
><br>
> I'm fine with moving to FileSystem, provided it is ready for production.<br>
> I see two possible ways to achieve that:<br>
> 1. create a layer on top of FileSystem which works like FileDirectory,<br>
> then release it and deprecate it. :)<br>
<br>
That's backwards.  FileDirectory is the smaller, faster, lower-level,<br>
more-utilitarian framework.  FileSystem is a "boutique" domain and<br>
framework with powerful high-level capabilities, but suffers from a<br>
performance-killing design issue.  So it'd probably make more sense<br>
for FileSystem use FileDirectory as its "primitive", and then we can<br>
simply keep FileDirectory around as-is for legacy apps.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
> 2. add FileSystem to the Trunk and gradually migrate all uses of<br>
> FileDirectory to it.<br>
<br>
This would be asking virtually every app to do a similar migration.<br>
All because of Squot?<br>
<br>
3.  Port Squot to use FileDirectory.<br>
<br>
4.  Don't port anything.  Side-by-side existence.  People who need<br>
Squot simply load Filesystem too.<br>
<br>
> > 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<br>
> > 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<br>
> > "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<br>
> > 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.<br>
><br>
> I don't think it is a good idea to mix MC and git at all. IMO we only<br>
> need tools to safely and reliably migrate from one to the other to start a<br>
> change.<br>
><br>
> Levente<br>
><br>
> ><br>
> > Am Mo., 18. Feb. 2019 um 11:45 Uhr schrieb Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>>:<br>
> >       On Mon, 18 Feb 2019, Jakob Reschke wrote:<br>
> ><br>
> >       > Am Mo., 18. Feb. 2019, 01:39 hat Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>> geschrieben:<br>
> >       ><br>
> >       >       Is it a must to use Metacello to load code in Tonel format?<br>
> >       >       What does Metacello add to the mix?<br>
> >       >       Can't we just map each git commit to an mcz?<br>
> >       ><br>
> >       >       Levente<br>
> >       ><br>
> >       ><br>
> >       > 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<br>
> >       Metacello. So I<br>
> >       > understand that Eliot wants it to work.<br>
> >       ><br>
> >       > 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<br>
> >       multiple packages<br>
> >       > 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<br>
> >       already supports<br>
> >       > these scenarios for FileTree repositories, albeit without using Monticello for the version control.<br>
> ><br>
> >       Looking at the repository in question[1], there seem to be multiple<br>
> >       packages stored in it[2]: BaselineOfScorch, Scorching, ScorchingDev,<br>
> >       ScorchingTests, ScorchingVMTests. My impression is that these could be<br>
> >       converted to individual mczs for each commit, which would mean that the<br>
> >       same code would be available as MC packages. Then you could load the code<br>
> >       with MC/Metacello/whatever from the .mczs.<br>
> ><br>
> >       Am I missing something?<br>
> ><br>
> >       Levente<br>
> ><br>
> >       [1] <a href="https://github.com/clementbera/Scorch" rel="noreferrer" target="_blank">https://github.com/clementbera/Scorch</a><br>
> >       [2] <a href="https://github.com/clementbera/Scorch/tree/master/repository" rel="noreferrer" target="_blank">https://github.com/clementbera/Scorch/tree/master/repository</a><br>
> ><br>
> >       ><br>
> >       ><br>
> ><br>
> ><br>
> ><br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>