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.
Le 28/06/2016 21:55, Dale Henrichs a écrit :
Thierry,
I don't think I can do it at all... I've deleted all of the packages,
I've removed all traces of the repository and when I add the repository
and inspect I get hasMetadata false...
I then deleted the metadata directory from every package on disk and
committed ... I then loaded the packages again from disk and made a
change and when I commit the change version number increments and voila,
I have a new monticello meta data directoy on disk free of charge ...
and yes hasMetadata is still false ...
I looked at the code and it seems that you are extracting the meta data
from the git repo (once you have meta data you must have meta data
forever?)
It looks like it is not possible to switch to metadataless which is a
shame ... all of the repos where I'd use this have monticello meta data
in the history so you'll find it if you go looking for it:)
This is a vcs, so, anyway, the monticello meta data will stay in the
history; you just have to checkout an old enough commit to get it :)
additional comments in-lined below ...
More comments below as well.
On 6/28/16 12:19 PM, Thierry Goubier wrote:
Hi Dale,
Le 28/06/2016 20:49, Dale Henrichs a écrit :
Thierry,
I think I tried the obvious:
1. open existing repository with gitfiletree://
2. reload all packages from gitfiletree repo and remove old filetree://
repo from each package
3. edit .filetree and add `"Metadata" : "false"`
but when I save a package I continue to get metadata created ...
With that sequence, I'm sure the gitfiletree repository in memory has
still kept the Metadata : true property, and so hasn't taken in
account the on-disk change. Like FileTree, it only loads the
repository properties on the very first access to that repository.
I even tried removing and adding the repo after editting the .filetree
file ....
And that didn't work ? I suspected it would... unless the gitfiletree
repository of step 1 above was not garbage collected.
I have a handful of additional random things that I will try, but I
think it is also time to find out the proper technique:)
I haven't provided an API for the switch, really. And I don't know
where to add that option inside the Monticello gui.
a Smalltalk expression or setting woudl be better than nothing ...
although it looks like the issue is deeper than simply changing the
metadata state:(
No, this was just that.
What I did, in the few cases I did it, was to inspect the in-image
MCFileTreeGitRepository and change the property in the inspector ;)
I want to gain experience with GitFileTree; test out the Metacello
Cypress mode; and perhaps honor the `"Metadata" : "false"` in the
GemStone version of FileTree ...
With a short time of usage, I would really like to be able to save all
of the packages in a project (including the BaselineOf) in one commit
... I often have multi-package units of work that really should be
committed together and of course if a method is moved across a package
boundary, the independent commits don't allow git to recognize the move
as a "rename" ...
We would need a specific API for that.
yep..
At the moment what would work is to save the baselineOf with all the
baseline packages as dependencies.
unless there have been radical changes to the way dependencies work,
this would defeat the purpose of having a baseline, i.e., all packages
get loaded when the baseline itself is loaded ...
Yes, but this is the only point where a MC repository sees a bunch of
packages to write to disk and not a single package.
Now, I'd like to be able to query the baseline to know which packages
it describes, and save all of them in one go.
I have this feature implemented in tODE ... of course in tODE I have
created a Metacello Project Browser that is used instead of a Monticello
Package Browser ... tODE still have the ability to manipulate packages
independent of the project, but the vast majority of the work is done by
loading and saving projects instead of packages ...
The upshot is that I have code that supports all of the necessary
functionality, but someone woule need to build a Metacello Project
Browser in Pharo to make this funcitonality available to users --- and I
don't have the bandwidth for that ...
So, what we would need is a project concept, and packages being loaded
via a baseline are added to that project, and, when saving, you
manipulate that project ?
Stef, I seem to remember you have planned for someone to work on Git
integration. I think this would be about the right feature to add,
combined with versionner...
Another possibility would be to add an option with a no-commit flag
(write but do not commit, do not try to update the package version)
and add a button to the window appearing after each written package
version to do the commit, store temporarily all such "staged" packages
info in the repository object, and provide a warning if one tries to
resave a package before a commit...
A poor man's project browser would have some additional menu items for
the BaselineOf package: save project and load project would probably be
sufficient. The you would go around a write all of the dirty packages
associated with the baseline ... in addition to the baseline itself ...
and then do your git commit when completed ...
Also I'm hoping that in metadataless mode I stop scanning the entire
known repository universe for package versions that will not be found
anywhere but in the repositories that I've explicitly associated with
the the package itself:)
I don't think it happens there. MCGitFileTreeVersionInfo already
tracks the repository it comes from, but I'm pretty sure that MC
doesn't ask the version info for the new data. Maybe add a new type of
WorkingCopy object?
When working with a metadataless repository why would need to look up
version info for the package in other repository?
In the past, the Monticello Browser would only look in the repositories
of the repository group for a package to look for package versions ...
now it seems that all of the repositoris in the default repository group
are scanned for versions of the package being committed.
I'll have a look and see if I can cut that in the case of GitFileTree
packages.
Thierry
Dale
