Cami, Agreed ... the monticello meta data is only necessary for backward compatibility (being able to move packages back and forth between mcz repos and git repos) .... there's an almost infinite number of ways that the Monticello definitions can be "cast in directory structure" and I'm not sure that there is an optimal format:) as different formats yield different tradeoffs ... Dale ----- Original Message ----- | From: "Camillo Bruni" <camillobruni@gmail.com> | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | Sent: Thursday, June 27, 2013 12:32:13 AM | Subject: Re: [Pharo-dev] Versions Browser over gitfiletree:// | | >> without Monticello file back-end no? | > | > No, in fact it's very much dependent on Monticello filetree back | > end. This backend has the granularity which allow a use of git | > querying / fetching facilities to the level associated with | > changesets. | > | > I could implement a use of a gitfiletree:// repo as a complete | > replacement of a live changeset + monticello repository in one, if | > needed. | > | > Still wondering if this is the way to go. | | I think it is a very good start :), | eventually we have to come up with second version of the filetree | format as | the current one has a major limitiation: categories are stored in the | method source | | Impact: | - md5 hashes of the pure ST method sources do not correspond the md5 | hashes in the | git repository | - each file-in requires another strip-the-category-path | | of course there are workarounds for that. Additionally I would love | to have a | filetree version that doesn't store all this MC metadata. The changes | in these | files generate so much noise that is it hard to see the actual | changes. | | Anyway, most of it is future talk, I guess the current approach will | work :) | | Though I wonder what we will do once we have custom slots :/. I guess | we need | some hacks to make that run on top of Monticello. |