Another slim implementation of Cypress decoupled from Monticello is the one I wrote for St/X:
https://bitbucket.org/janvrany/stx-goodies-cypress/src or in Cypress format itself: On Wed, 2015-11-25 at 21:42 +0100, Thierry Goubier wrote: > Hi Dale, > > thanks for the update. So not only it would be possible to extract > FileTree from its relation to Monticello, this has in fact already > been > done (and more than once). > > Thierry > > Le 25/11/2015 20:33, Dale Henrichs a écrit : > > > > > > On 11/25/2015 02:31 AM, Thierry Goubier wrote: > > > > > > > > > 2015-11-25 10:39 GMT+01:00 Skip Lentz <skip.le...@inria.fr > > > <mailto:skip.le...@inria.fr>>: > > > > > > > > > > I think having a FileTree reader/writer that is not > > > > coupled > > > > to Monticello would be good, but maybe I’m saying > > > > something > > > > that is not possible. > > > > > > > > > > > > No, it is possible (everything is), but a bit complex for > > > > maintenance (how do you track changes and corrections in > > > > the > > > > FileTree code?). > > > > > > Of course, the sky is the limit :P. Although I’m not sure I > > > understand what you mean here, could you explain? > > > > > > FileTree has a large set of test cases, sample repositories, CI > > > setup, > > > cross-platform knowledge, bug fixes coming from a large group of > > > users > > > (far larger than the Pharo community). > > > > > > Cutting ourselves from that is counter productive and looks like > > > a > > > case of the NIH syndrome. > > > > > > > Thierry, > > > > I understand where you are coming from with your comment and I am > > not > > necessarily disagreeing with you, but:) > > > > A "FileTree reader/writer that is not coupled to Monticello" is not > > necessarily a bad thing and in fact I have implemented such a beast > > a > > couple of times[1][2] and I think that Jan based his initial > > implementation on the Pharo Cypress implementation[5]. > > > > My initial implementation[1] was done in support of Amber > > Skeleton[3][6] > > where I added implemented an Amber source code server in Pharo and > > used > > the Cypress reader/writer[1] to pass packages back and forth > > between > > Amber and Pharo once the package hit Pharo it was written to disk > > using > > FileTree. > > > > The second implementation[2] was done to implement a FileTree > > reader/writer for Cuis which does not use Monticello, so I needed a > > reader/writer that understood the FileTree disk format without > > being > > coupled to the Monticello package implementation and loader. > > > > Richard Sargent has a Cypress reference implementation for GemStone > > that > > is also independent of Monticello[4]. > > > > These Cypress implementations read/write the FileTree disk format > > without being coupled to the in-image Monticello implementation ... > > the > > definition model and loaders are basically stripped down versions > > of the > > Monticello implementations, with the major difference being the > > absence > > of the Monticello meta data --- ancestors and the like --- which > > means > > that in a world where you rely on the disk-based scm to manage > > versions, > > there is no need to have the Monticello meta data in the image at > > all ... > > > > Skip will be downloading individual files from GitHub and will need > > to > > construct a coherent package model from those files and > > directories. > > There may be an advantage to constructing "Cypress snapshots" from > > the > > raw GitHub data as an intermediate format if nothing else - much as > > I > > did for the Amber Skeleton project .... > > > > If there is interest in moving forward with the Pharo Cypress > > code[1], I > > would be in favor of splitting that code out into a separate > > project, so > > that it can evolve independent of it's Amber Skeleton roots ... > > > > Dale > > > > [1] > > https://github.com/CampSmalltalk/Cypress/tree/master/implementation > > s/pharo/cypress/packages > > [2] > > https://github.com/CampSmalltalk/Cypress/tree/master/implementation > > s/cuis/packages > > [3] https://github.com/dalehenrich/amber-skeleton/tree/master/serve > > r > > [4] https://github.com/rjsargent/CypressReferenceImplementation > > [5] > > https://github.com/CampSmalltalk/Cypress/tree/master/implementation > > s/smalltalkx/packages/stx_goodies_cypress.package > > [6] https://github.com/CampSmalltalk/amber-cypress > >
