Hi Dale,

Le 29/06/2016 01:50, Dale Henrichs a écrit :
Thierry,

Okay ... it is "working" now ... I was also misled by the fact that you
are continuing to fabricate Monticello version numbers which presumably
cannot be relied upon in any way.

Tugrik-Help-DaleHenrichs.11 will show up in each branch that includes
the commit for "Tugrik-Help-DaleHenrichs.10", but the SHA and contents
would be different for each one of the "Tugrik-Help-DaleHenrichs.11" ,
is that right?

Yes.

Perhaps using the short SHA in place of the "version number" would be
safer and provide useful information in the version number slot?

Maybe. But then you'll have a bunch of stuff expecting version numbers that will stop working.

If I support "Metadata" : "false" in GemStone, I do not intend to
fabricate a "realistic looking Monticello version number" ... but I will
look into using the short SHA (when in a git repo) and perhaps fall back
to cypress.1 for non-git repos...

Anyway, I will now be able to move forward with my Metacello Cypress
experiments and also try to understand how Metacello loads are affected
by metadtaless, since you _are_ fabricating Monticello version numbers,
my previous assumptions are not correct ...

Please tell how it goes, especially the part with the short SHA, because I haven't tried that; I kept creating version numbers to just have gitfiletree behaving like filetree (apparently).

Thierry

Thanks again!

Dale

On 6/28/16 4:11 PM, Dale Henrichs wrote:


On 6/28/16 2:16 PM, Thierry Goubier wrote:
Dale,

I'm sure it is possible. Wait, wait! If you have in your .filetree
"Metadata" : "false" then this is fine and it has switched to the
metadata-less mode.

To see the changes on disk, you need to save a new version of your
packages, that should be all.

I just tried and that works.

1- remove the GitFileTree repository from your image
2- write the property "Metadata" : "false" in the .filetree on disk
3- re-add the GitFileTree repository (local)
4- modify then save one of the repository packages
5- look on disk: no more monticello.meta/version!

Note that I had no packages in the image linked to that repository at
1-, because I'm not sure the simple removal would have really removed
the repository singleton object.
Well I've found the culprit: MCFileTreeWriter>>addString:at:encodedTo:
ensures that monticello.meta directory exists...

Of course as I reread your comment "no more monticello.meta/version" I
will have to say that I've only been looking at whether or not the
monticello.meta directory existed or not ... I equate "no monticello
meta data" as no monticello.meta directory and you interpret it as "no
monticallo version file" ... well I can live with that ... I swore
that I saw version files being updated in some of my experiments ...
but now that I know that I should only look at the
monticello.meta/version file, I will try yet again ...

Thanks for you patience and help ...

Dale






Reply via email to