On 11/25/2015 02:31 AM, Thierry Goubier
wrote:
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/implementations/pharo/cypress/packages
[2]
https://github.com/CampSmalltalk/Cypress/tree/master/implementations/cuis/packages
[3] https://github.com/dalehenrich/amber-skeleton/tree/master/server
[4] https://github.com/rjsargent/CypressReferenceImplementation
[5]
https://github.com/CampSmalltalk/Cypress/tree/master/implementations/smalltalkx/packages/stx_goodies_cypress.package
[6] https://github.com/CampSmalltalk/amber-cypress