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