Oops, sorry - accidentally sent unfinished message 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: https://github.com/CampSmalltalk/Cypress/tree/master/implementations/sm alltalkx/packages/stx_goodies_cypress.package though this might be a little behind, I'll check an eventually update soon(ish) It has the nice feature of keeping all files and properties it does not understand, though this behaviour is *not* required by Cypress spec. Best, Jan > > 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 <[email protected] > > > > <mailto:[email protected]>>: > > > > > > > > > > > > > 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/implementati > > > on > > > s/pharo/cypress/packages > > > [2] > > > https://github.com/CampSmalltalk/Cypress/tree/master/implementati > > > on > > > s/cuis/packages > > > [3] https://github.com/dalehenrich/amber-skeleton/tree/master/ser > > > ve > > > r > > > [4] https://github.com/rjsargent/CypressReferenceImplementation > > > [5] > > > https://github.com/CampSmalltalk/Cypress/tree/master/implementati > > > on > > > s/smalltalkx/packages/stx_goodies_cypress.package > > > [6] https://github.com/CampSmalltalk/amber-cypress > >
