On 6/29/16 5:30 AM, Thierry Goubier wrote:
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).
when you are doing the next version number calculation, you only need
the first ancestor (the ancestor that is loaded in the image) ... to
find whether or not team members have committed new versions involves
scanning the packages in the repositories in the repository group and
picking up the first version in the ancestry ...
it seems for a working copy that only the first ancestor is needed in
the image ... the rest can be lazily loaded if one wants to see history ...
The new versions committed by team members aren't even in the ancestry
of the working copy ...
I have not looked at the details of the caching that is used by the
repository implementation with respect to versionInfo, but if my
allInstances yesterday is any indication, it is/was always necessary to
scan the repositories in the repository group to look for newer versions
of the package but the version info for those scans wasn't necessarilyt
cached anyway ...
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.
Right ... so close counts in Monticello version numbers and horse shoes :)
Dale
