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