Metacello GIT methodProperties.json

2015-04-08 8:47 GMT+02:00 Peter Uhnák <[hidden email]>:

I thnk that rather than focus on the disk format which I hardly ever actually look at ... that folks should be looking at tools support (like Thierry) ... this is where the real work needs to happen ... good tools can hide the disk fomat completely so why does the disk format matter ...

I am personally not really a fan of this; I've been using git for a while and I am perfectly content with using command line on the disk (maybe I'm rare breed); I have yet to see a GUI/tool that would come even close to the power of command line, but I've been using Linux for a long time.

Agreed and this is in that spirit I did GitFileTree. Dale went a bit further and even integrated the git command line access inside smalltalk via CommandShell... so that you get the best of both worlds without leaving your beloved Smalltalk :)

Actually it is not quite CommandShell based ... the shell is tODE shell, where Smalltalk is the scripting language. The tODE git commands  are implemented by parsing the command line args, resolving options and args to objects, and then calling a Smalltalk git command API that eventually does make shell calls (sometimes multiple git commands are folded into a single tODE git command ... thus making it possible to ultimately switch out the actual `git calls` and use something FFI-based, like libgit2...

This approach also makes it quite feasible to write fairly complicated Smalltalk scripts that call the smalltalk git command api directly, bypassing the command line interface altogether ...

 

As I've said to Thierry some time ago in different thread, I would be interested in idea of having everything on disk side and Pharo would only somehow refresh it's content (just like a Java IDE / text editor would). But that may be a lot o work so I can only dream about it, as nobody has time for that (me included).

Well, as I said elsewhere, Smalltalk doesn't work like that: code has to be lived in the image for most tools to work properly... it doesn't really have an "editor of file" mindset, but an "object inspector" mindset.

What we're looking at in another thread is how to emulate that live object approach over dead files, and, thinking of it, I'm not sure we will succeed well.

In short, what you want may never work properly because it is not how it should be conceptualized.

 

In tODE I regularly drop off live objects to the file system using STON ... The tODE shell which allows you to navigate an object-based directory also allows you to mount the nodes from the file system and when traversing the file system recognizes STON files and presents objects to you instead of the dead files:)

I haven't tried taking this approach all the way to source files ... but????

Dale

On 04/08/2015 12:47 PM, Thierry Goubier wrote: The work I had done was at the Metacello level and is in the
Metacello-Cypress package where I changed the load semantics to
unconditionally load the package ... the snapshot comparison logic in
play when loading packages is pretty good so it isn't necessarily a
penalty to unconditionally compare snapshots when loading a package from
FileTree ...
So this "extraneous" Monticello meta data is really related to the
versioning aspects of the Monticello package ... aspects that really
needed if you are using "git" (read "git" as svn, hg, git, fossil,
etc.:) for version control .. in working with "git" the SHA of the
commit for the repository as a whole is more important than any of the
package meta data ... from the SHA one can see the commit comment for
the "git" commit the SHA is related to a project not a package ... the
project contents is represented by the BaselineOf ... in git one can
reason about the collection of commits associated with a directory
(package or class or method) and look at diffs at that level of
granularity .... The primary point being that a "git" package can be
stripped down to the basic list of definitions and the ancestry and
version names and method properties can be dropped on the floor instead
of fabricated ...

What I imagine is a separate software stack for these "git" packages the
commonality is at the snapshot/definition level and the core definitions
can migrate between Monticello and "git" packages almost without change
... if one wanted to know the "history" of a package the Monticello
package would answer back a representation of the ancestor graph, while
the "git" package would answer back a representation of the commit
history ... there would be different objects in the histories, since the
meta data for extracting the useful bits varies considerably between the
two package implementations, but from a tools perspective and arranging
for a common tool-level api would be able to accommodate these two
completely different packages as well as any number of package
implementations that could wrap packages stored in the wide variety of
SCMS floating around out there .... and those to come ... what the hell:)

Well there's a year or so of work:)

Dale