[Cuis] OSProcess status

Frank Shearar frank.shearar at gmail.com
Fri Dec 20 08:38:35 CST 2013


On 20 December 2013 14:15, Juan Vuletich <juan at jvuletich.org> wrote:
> On 12/18/2013 8:42 AM, Frank Shearar wrote:
>>
>> On 18 December 2013 03:45, Juan Vuletich<juan at jvuletich.org>  wrote:
>>>
>>> ...
>>>
>>> Given that extracting the code from a MCZ file is not hard, I could write
>>> a
>>> simple tool to allow converting an MCZ file to .pck.st format. This tool
>>> would also convert newline characters (cr, crlf, lf) to Cuis default: lf.
>>
>> How difficult do you think it would be to write the reverse tool,
>> converting a .pck.st to MCZ? I'm thinking of something that could say
>> "I depend on this repository, at this commit id" and grab something
>> from github. The user just sees an MCZ. I suspect the hard part is the
>> fact that an MCZ has a UUID identifier and a funny name. Something
>> would need to remember that this tag in the git repository mapped to
>> this (UUID, author, version number) triple. A masochist would suggest
>> storing that in the tag itself...
>
>
> I don't know. I've been avoiding learning too much about the internals of
> Monticello. Given that .pck.st is esentially a changeset, this question is
> better suited to Monticello experts.
>
> BTW, you are thinking about making tools aware of GitHub. I think it better
> to manage repos with their own tools, and just use the file system from
> Smalltalk.

The opposite, actually: if I can map git commits containing changesets
to Monticello packages, I can have all the MC tools Just Work(tm). One
option is to have a postcommit hook in the git repository that
publishes an MCZ based off the changeset, I suppose. (MCZs look a
whole lot like jar files, which are closer to deployable artifacts
than source code revisions.)

frank


> Cheers,
> Juan Vuletich




More information about the Cuis mailing list