Basic versioning of GitHub repositories from within Pharo

> Hi,
>
>> On Nov 24, 2015, at 5:30 PM, Skip Lentz <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> I will set up a GitHub repository tomorrow. Right now it’s on
>> SmalltalkHub, but I think it’s a good idea to put it on GitHub (if
>> only for doing versioning with the tool itself). Then you’ll be able
>> to fork etc.
>>
>> I’ll report back in this thread.
>
> The migration to GitHub has been done, the repository is found here:
>
> https://github.com/Balletie/GitHub
>
> I wonder if the repository name is a problem... I saw other bindings use
> this name as well though.
>
> I migrated all commits in chronological order, and switched to using
> BaselineOf.
>
> Installation instructions are included in the README. This repository is
> not metadata-less because otherwise I found no way to load it using
> Metacello.
>
> Lastly, I have added several issues already (bugs, enhancements) to the
> issue tracker. Feel free to add your own of course ;)

>
>
> On 11/25/2015 02:31 AM, Thierry Goubier wrote:
>>
>>
>> 2015-11-25 10:39 GMT+01:00 Skip Lentz <[hidden email]
>> <mailto:[hidden email]>>:
>>
>>
>>>         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

> 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 <[hidden email]
> > > <mailto:[hidden email]>>:
> > >
> > >
> > > >         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
>
>

>
> 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 <[hidden email]
> > > > <mailto:[hidden email]>>:
> > > >
> > > >
> > > > >         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
> >