Le 24/08/2015 18:11, stepharo a écrit :
I wanted to harvest the changes in squeak to have MCName but I failed a
couple of years ago.
Do you know what those changes are? Many of the things I thought were
wrong with MC naming a while ago do not matter anymore once moved to
git. Now MC naming quirks are just annoying :(
Now relying on name is a bad idea (we got sometimes burnt by that).
The numbering is user-friendly, but unreliable... A safe numbering would
be less user-friendly, IMO.
Thierry
Stef
Le 24/8/15 00:00, Thierry Goubier a écrit :
Le 23/08/2015 22:00, Yuriy Tymchuk a écrit :
Thanks Thierry!
I’m not completely aware about the issue details, but maybe it makes
sense to change something in metacello itself?
No, not really, or maybe in a very complex way...
The issue is inside Monticello, in the way the Monticello GUI
interacts with each package version history, and how that interacts
with the lazy version info I added late in the Pharo 4 development cycle.
The Monticello GUI is designed to be able to display the newer/not
newer version feedback (you know, the underlined, bold, non bold
package version status you see in a repository) out of two things:
first the complete knowledge of the complete version history of all
the packages loaded in the image. And second, the names of the mcz
files in the repository. Why the names? To avoid downloading all the
mcz in the repository to get their version history... Monticello just
pray and hopes the names are right... Oh, by the way, Gofer also prays
and hopes that the names are right when you are loading something via
a configuration and a script[*].
When I added[**] lazyness to the version history in the image, I
removed that complete history Monticello relies on (and a bit of
memory out of the image). And, as a result, this has immediately
created issues in the GUI that are taken care of as they come. Some
are simple, like the gitfiletree ones, because you get all the proper
version history with a few git commands in the repository. But you
can't do that with a http repository (smalltalkhub, squeaksource)
since you can't get the remote repository version history.
Thierry
[*] Which is very fun because, at times, the names aren't right... and
the wrong package get loaded. Incomprehensible pain and confusion ensue:(
[**] I'm the second guy doing this lazy thing with Monticello.
Smalltalk/X seems to had (have?) the same thing before. Would like to
share the experience one day;)
Uko
On 23 Aug 2015, at 20:26, Thierry Goubier
<[email protected]> wrote:
Hi Nicolas, Uko,
I added an optimisation to gitfiletree which avoids the unnecessary
loading all file names. Available on Pharo4 and Pharo5 (development
and stable).
Thierry
Le 23/08/2015 09:08, Nicolas Anquetil a écrit :
worse than that
last week over a slow connection, I noticed that it "loaded all file
names" (from Pharo40Inbox in my case) over and over again
nicolas
On 22/08/2015 21:29, Yuriy Tymchuk wrote:
Hi,
I’ve noticed that when I try to open a gitfiletree repo, before
displaying its contents something from meta repos is loaded (seen on
screenshot). Why does it need file names from meta repos to display
contents of the repo which is present on my machine?
Uko
