Posted by
Dale Henrichs-3 on
Apr 08, 2015; 9:45pm
URL: https://forum.world.st/Metacello-GIT-methodProperties-json-tp4818097p4818460.html
On 04/08/2015 12:47 PM, Thierry Goubier wrote:
> Hi Dale,
>
> Le 08/04/2015 19:30, Dale Henrichs a écrit :
>>
>>
>> On 04/07/2015 10:24 PM, Thierry Goubier wrote:
>>> Le 08/04/2015 02:05, Dale Henrichs a écrit :
>>> I have threatened in the past to add an option to a repository that
>>> would eliminate the need to store monticello meta data ... Damien is
>>> working on "starting from scratch" on the new format, because the
>>> current implementation supports 4-5 different FileTree formats.
>>> Damien's
>>> work could be leveraged to add an "optional Monticello meta data"
>>> option
>>> to FileTree and if your SCM (like git) gives you per method history
>>> with
>>> the proper tools you can leverage that information..
>>>
>>> I would say this could be a reasonable possibility, in that you could
>>> have two modes of compatibility:
>>>
>>> - Complete filetree compatibility for gitfiletree: the current
>>> situation, with properties and version written to disk.
>>>
>>> - Partial filetree compatibility, where that metadata isn't written
>>> and you rely on gitfiletree to recreate it to export as .mcz.
>>>
>>> Partial compatibility has two effects, which need to be considered.
>>> When using github:// or bitbucket:// urls, filetree will be used and
>>> your packages will end up having no version number (except .1?), no
>>> author, no timestamps for methods, etc... And the second one is that,
>>> if you clone a mcz inside the gitfiletree repository, the mcz ancestry
>>> of versions and author timestamps on methods will be lost, which is
>>> something you may not want.
>> Yes for Metacello some modifications would need to be made because in a
>> normal mcz universe Metacello will not load a package if the version is
>> older or the same as the one in the image ... and following in the
>> tradition of other Monticello tools the UUID is ignored:( .. I was
>> working with a pure cypress implementation and have written the
>> Metacello code to support these repos ...
>
> Ok.
>
> Yes, the version number handling is delicate; even the one used by
> gitfiletree feels unsatisfying, even if it allows Metacello/Monticello
> to work as usual.
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 ...
>
>> A better long term solution is to treat these as a CypressPackage or
>> FileTreePackage which has some similarities to Monticello packages ...
>> because faking out Monitcello version numbers and users is not much
>> different than storing the metadata in FileTree ...
>
> Not sure I understand. I know where the Cypress/FileTree code handles
> the lack of metadata when reading, that's all :)
>
>> But someone were to add those options to filetree, I think we could
>> reduce the overall number of hacks:)
>
> Another solution I'd see possible is a reduced metadata format, where
> just the version number of the current package is stored and retrieved
> (i.e. a version file without ancestry).
>
> It would allow FileTree and Metacello to work exactly as usual.
>
> And, maybe, I could even unify the UUIDs?
>
> There are things in Monticello which needs a rethink to better adapt
> to SCMs like git (or Fossil: it's so similar to git :) ) while keeping
> more or less the same appearance: branches, hashes, tags and semantic
> versionning.
>
> But I don't see yet how to handle that or to propose anything.
>
> I know that it would be great to reduce the cognitive distance between
> MC version and history handling, and the same as seen from Metacello
> baselines and configurations. Branches + baselines are doing a lot to
> simplify, but MC stuff is unaware of that. And MC should delegate
> merging to the underlying repository, as well.
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