[ANN] No-Metadata mode for GitFileTree

> Oh yes,
>
> I can announce that from now on, the development version of
> GitFileTree for Pharo 5 handles FileTree repositories without most of
> the metadata (precisely version and methodProperties).
>
> This makes the format a lot more DVCS friendly (Git, Fossil, Hg, SVN,
> all...) by cutting the noise on diffs and conflicts on merge and
> cherry picking.
>
> Note: it only apply to brand new repositories; nothing is changed for
> pre-existing ones.
>
> Note2: reading those Metadata-less repositories with FileTree does
> give you packages without metadata: no version history, no author, no
> author nor timestamp on methods.
>
> Note3: it is possible to hack a repo from metadata to non-metadata
> mode, but I won't explain it.
>
> Enjoy and tell me how it works for you. I'm especially interested by
> heavy branchers/mergers reports :)
>
> Thierry
>

>
>
> On 11/7/15 10:00 AM, Thierry Goubier wrote:
>> Oh yes,
>>
>> I can announce that from now on, the development version of
>> GitFileTree for Pharo 5 handles FileTree repositories without most of
>> the metadata (precisely version and methodProperties).
>>
>> This makes the format a lot more DVCS friendly (Git, Fossil, Hg, SVN,
>> all...) by cutting the noise on diffs and conflicts on merge and
>> cherry picking.
>>
>> Note: it only apply to brand new repositories; nothing is changed for
>> pre-existing ones.
>>
>> Note2: reading those Metadata-less repositories with FileTree does
>> give you packages without metadata: no version history, no author, no
>> author nor timestamp on methods.
>>
>> Note3: it is possible to hack a repo from metadata to non-metadata
>> mode, but I won't explain it.
>>
>> Enjoy and tell me how it works for you. I'm especially interested by
>> heavy branchers/mergers reports :)
>>
>> Thierry
>>
> Thierry,
>
> You want to double check that Metacello works correctly with these
> metadata-less packages ... if you are continuing to increment the
> "package version" there shouldn't be a problem, but when I did a similar
> experiment a year or so ago, I found that I had to teach Metacello to
> ignore the "package version" and load the package anyway ... the normal
> procedure for Monticello packages and Metacello is not load a package if
> the "package version" is less than or equal to the package already
> loaded .... I did make an extension to Metacello to make this work ....
> I can hunt it up if needed and make it part of the standard release (I
> may have kept it as part of tODE) ...

>
>
> On 11/7/15 10:00 AM, Thierry Goubier wrote:
>> Oh yes,
>>
>> I can announce that from now on, the development version of
>> GitFileTree for Pharo 5 handles FileTree repositories without most of
>> the metadata (precisely version and methodProperties).
>>
>> This makes the format a lot more DVCS friendly (Git, Fossil, Hg, SVN,
>> all...) by cutting the noise on diffs and conflicts on merge and
>> cherry picking.
>>
>> Note: it only apply to brand new repositories; nothing is changed for
>> pre-existing ones.
>>
>> Note2: reading those Metadata-less repositories with FileTree does
>> give you packages without metadata: no version history, no author, no
>> author nor timestamp on methods.
>>
>> Note3: it is possible to hack a repo from metadata to non-metadata
>> mode, but I won't explain it.
>>
>> Enjoy and tell me how it works for you. I'm especially interested by
>> heavy branchers/mergers reports :)
>>
>> Thierry
>>
> Thierry,
>
> You want to double check that Metacello works correctly with these
> metadata-less packages ... if you are continuing to increment the
> "package version" there shouldn't be a problem, but when I did a similar
> experiment a year or so ago, I found that I had to teach Metacello to
> ignore the "package version" and load the package anyway ... the normal
> procedure for Monticello packages and Metacello is not load a package if
> the "package version" is less than or equal to the package already
> loaded .... I did make an extension to Metacello to make this work ....
> I can hunt it up if needed and make it part of the standard release (I
> may have kept it as part of tODE) ...
>
> Dale
>
>

> Le 08/11/2015 17:41, Dale Henrichs a écrit :
>>
>>
>> On 11/7/15 10:00 AM, Thierry Goubier wrote:
>>> Oh yes,
>>>
>>> I can announce that from now on, the development version of
>>> GitFileTree for Pharo 5 handles FileTree repositories without most of
>>> the metadata (precisely version and methodProperties).
>>>
>>> This makes the format a lot more DVCS friendly (Git, Fossil, Hg, SVN,
>>> all...) by cutting the noise on diffs and conflicts on merge and
>>> cherry picking.
>>>
>>> Note: it only apply to brand new repositories; nothing is changed for
>>> pre-existing ones.
>>>
>>> Note2: reading those Metadata-less repositories with FileTree does
>>> give you packages without metadata: no version history, no author, no
>>> author nor timestamp on methods.
>>>
>>> Note3: it is possible to hack a repo from metadata to non-metadata
>>> mode, but I won't explain it.
>>>
>>> Enjoy and tell me how it works for you. I'm especially interested by
>>> heavy branchers/mergers reports :)
>>>
>>> Thierry
>>>
>> Thierry,
>>
>> You want to double check that Metacello works correctly with these
>> metadata-less packages ... if you are continuing to increment the
>> "package version" there shouldn't be a problem, but when I did a similar
>> experiment a year or so ago, I found that I had to teach Metacello to
>> ignore the "package version" and load the package anyway ... the normal
>> procedure for Monticello packages and Metacello is not load a package if
>> the "package version" is less than or equal to the package already
>> loaded .... I did make an extension to Metacello to make this work ....
>> I can hunt it up if needed and make it part of the standard release (I
>> may have kept it as part of tODE) ...
>
> Hi Dale,
>
> GitFileTree without metadata on disk does not mean no metadata for
> Monticello/Metacello to work with; as long as you reach the git log
> info, then it will work exactly as usual (incrementing version
> numbers, etc...), with the usual caveats (i.e., if you limit depth
> when cloning with git, version numbers do change).
>
> However, when accessing via FileTree (for example github:// urls),
> then, yes, version numbers become 1.
>
> It will only matter when updating an already loaded project via a
> github:// or bitbucket:// url. And there, simply allowing Metacello to
> load if repository version is >= to existing version should take care
> of it.

> Hi Dale,
>
> I'm back at that again.
>
> And I think that Metacello is already failing with repositories that
> have true branches (git + filetree). Metacello delegates to Monticello
> which rely on full ordering to establish upgrades or loading
> preferences. And on repositories with branches, each branch has its
> own ordering, making upgrades a possible problem (such as switching to
> a new branch with a new version and discover there that the top of
> that branch has a lower version number than the previous version == no
> load).

>
>
> On 11/9/15 5:08 PM, Thierry Goubier wrote:
>> Hi Dale,
>>
>> I'm back at that again.
>>
>> And I think that Metacello is already failing with repositories that
>> have true branches (git + filetree). Metacello delegates to
>> Monticello which rely on full ordering to establish upgrades or
>> loading preferences. And on repositories with branches, each branch
>> has its own ordering, making upgrades a possible problem (such as
>> switching to a new branch with a new version and discover there that
>> the top of that branch has a lower version number than the previous
>> version == no load).
> Hmmm ... I can see that this could happen ...
>>
>> Granted, this is less probable, but could surprise...
> I don't like surprises:)
>>
>> Now, if Metacello could use the semantic versionning present in the
>> Configurations and Baselines...
> Semantic versioning is only used in ConfigurationOf subclasses ... the
> notion with git is that the branch should be loaded whether or not it
> is an "Monticello package upgrade" or not... I'll have to think on
> this one a bit .... I'm in Buenos Aires for Smalltalks this week ...
> but I consider this to be somewhat of a major bug, given that folks
> are moving more and more to git .... it may be as "simple" as turning
> on the "cypress url" for all FileTree repos .... but I want to think
> through this one a bit more ...
>
> Dale
>