On 6/29/16 1:00 AM, Thierry Goubier 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.
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.
That's not true. Each working copy has repository group where either the
developer has either explicitly declared the set of repositories that
are associated with the working copy and/or the system has recorded the
set of repositories from which the package has been loaded ... you
should restrict the search to the repos in the repository group.
(at the same time, restricting version number determination to a
subset of the repositories is against MC principles when numbering
versions).
In principle, yes, but from a practical point of view, the version
number search was "always" restricted to the set of repositories in the
repository group for the working copy ... keep in mind that putting
version numbers in the package name is a _convention_. I don't think
that Monticello ever defined a package name syntax ... Technically,
Monticello is supposed to use the UUID to disambiguate between to
packages with the same name, but as you and I know, this is not really
enforced in the code --- Monticello evolved to rely on the version
number for ordering package versions, but I don't think that was ever
part of the design of Monticello ... if you look at the older
implementations of the tools, there was no enformcement of any rationale
package naming scheme ...
I agree that today when looking at the point to which Monticello usage
has evolved that the statement:
"the only way to guarantee a unique version number for a package is
to scan all available repositories"
is absolutely true, but even then there is no guarantee that a duplicate
package does not exist in a repository that is not connected to the repo ...
However, Monticello is also tolerant of packages with the same name and
in practice, the same author rarely if ever produces two different
versions of a package with the same name (unless they do it on purpose)
and of course two packages with the same name cannot coexist in a single
mcz repository, so this condition is even more rare and not necessarily
worth scanning all connected repos ....
