Posted by
Thierry Goubier on
Apr 08, 2015; 7:35pm
URL: https://forum.world.st/Metacello-GIT-methodProperties-json-tp4818097p4818445.html
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.
> 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.
Thierry