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.
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,
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.
I understand that ... but for writing out dirty packages in a Metacello
project this is not a viable alternative...
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 ?
Actually, Metacello has a registry of loaded projects (baselines and
configurations) and using Metacello it is possible to determine which
pacakges belong to which projects etc. so it is not necessary to
"register packages with a project" ... the project registry in Metacello
is enough ...
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...
Yep I agree ... and as I have often said, I've written code in tODE that
uses Metacello to manage projects with a host of git support features as
well ... and I would gladly offer advice and assistance to help someone
adapt the code/lessons that I've larned with tODE to Pharo ... I have
built a definition model upon which a number of the tools are based, but
it is probably time for a next generation implementation ...
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.
I'm pretty certain the MCLazyVersionInfo is the real culprit here ...
while reading the code I recognized that many of the basic patterns were
exactly as I had remembered them from years ago ... however ...
MCLazyVersionInfo this puppy with its "default behavior" to scan the
universe is the real culprit ... I would think that at a minimum the
repository or repository group would/could be know at the time that the
MCLazyVersionInfo was created and a scan of just those repositories ---
already associated with the project --- would not be nearly as bad as
when we have now ...
Dale
