BTW, I loaded git file tree with the Catalog Browser, so I'm not
necessarily using the latest code from Github:
BaselineOfGitFileTree-ThierryGoubier.16
Dale
On 6/28/16 12:55 PM, Dale Henrichs wrote:
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:)
additional comments in-lined below ...
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:(
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 ...
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 ...
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.
Dale
