Le 29/06/2016 12:57, Ben Coman a écrit :
On Wed, Jun 29, 2016 at 4:00 PM, Thierry Goubier
<[email protected]> wrote:
Le 29/06/2016 00:55, Dale Henrichs a écrit :


...


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 ...


The MCLazyVersionInfo thing is mine too; it was a solution to avoid keeping
MBs of version info kept inside the image memory, with the cost of having to
reload that information when you access the ancestry.

Would it be feasible to drop all those MB except keep the latest
version of a package in-Image,
i.e. the one required to determine the next version number of the package. ?

This is not considered enough for Monticello. If you are on a multi-people team with a smalltalkhub repository, keeping memory of myPackage.7 is not enough because your team members may push .8, .9, etc... before your save, and your save should be .10, not .8. So an access to the remote repository is necessary (and all of them; maybe you're working with multiple smalltalkhub repositories for that package).

Of course, MC does not lock the remote repository while you do that, so the number it generates at the beginning (just before you get the window where you fill in the package version comment) is not guaranteed to be up to date if a team member saves a new version in the mean-time.

Of course, MC does not forbid you to change by hand the version number.

Thierry

cheers -ben

Now, the approach needs to be tuned to avoid spurious "query the world"
searches, but, as you point out, I hasn't been too successfull yet. And one
of the thing MC lack, is that link between a repository and a working copy.

(at the same time, restricting version number determination to a subset of
the repositories is against MC principles when numbering versions).

Thierry





Reply via email to