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/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
