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
