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.
Sorry, this does not work for me .... this is the first thing I tried
and of course I looked very carefully to ensure that the packages were
gone and the repository was not referenced anywhere...
I spent a fair amount of time reading the git filetree code to try to
understand who is creating the monticello.meta directory and reading all
of your code, I could not find any obvious culprits.... so I don't think
that your code is directly responsible for the creation of the metadata
dir...
However, I just sprayed a bunch of self halts into the code in an
attempt to find out who might be causing the directory to be created and
I tripped across MCLazyVersionInfo who I think is the culprit for the
"scanning the entire known universe" and _might_ be the culprit for
"lazily" creating the "missing" monticello.meta directory - I haven't
gotten that far yet.
With regards to "scanning the entire known universe". It looks like any
sender of #ancestors (which is not an unusual thing during save --- my
current case or diff another case where I've seen the full scan) to an
instance MCLazyVersionInfo can end up doing following:
MCRepositoryGroup default in: [ :r | r versionWithInfo: self ifNone:
[ ] ]
which literally scans the entire repository universe ... This is part of
the method #loadAncestorsAndStepChildren which is documented to: "This
code scans all the repositories to find the exact package version and
reload the relevant info."
In my image I have 475 instances of MCLazyVersionInfo and 481 instances
of MCWorkingCopy (without knowing for certain, I'll speculate that the 6
working copies without MCLazyVersionInfo are the 6 packages that are
instances of MCGitFileTreeVersionInfo a subclass of MCLazyVersionInfo)
... The MCLazyVersionInfo caches the result of the full universe scan in
a WeakArray ... so if there's an intervening gc (or two) between the
time that one saves a package, the full repository scan will be re-run
again ... and again ... and again ..
So I think I now understand why I see so many scans of the pharo inbox
and presumably all of the repos almost every time I save a package ...
not very friendly...
This scan was triggered when I tried to save one of the packages that I
had just loaded and in this case the MCGitFileTreeVersionInfo triggered
a scan because the repo instance variable was nil ... perhaps this is
the difference between your run and mine ... in my case the repo was not
set correctly and in your case it was?
Hopefully someone will do something about this "lazy version info
problem" personally I would gladly trade off some memory and disk
consumption to avoid having to wait for the entire repository universe
to be scanned every time I save a package ...perhaps there is a setting
somewhere?
I will continue trying to work through meta data directory creation
problem and see if I can pinpoint the metadata dir creation culprit ...
right now I know that the packages are loaded without creating the
directory ...
Dale
