Hi Norbert,
Le 30/06/2016 08:51, Norbert Hartl a écrit :
Am 30.06.2016 um 01:26 schrieb Dale Henrichs <dale.henri...@gemtalksystems.com>:
On 6/29/16 3:44 PM, Ben Coman wrote:
On Thu, Jun 30, 2016 at 3:04 AM, Dale Henrichs
<dale.henri...@gemtalksystems.com> wrote:
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"
What if rather than being incremental the Monticello number what
generated YYMMDDhhmmss? Should be reasonably compatible with that
scope creep of version numbers into Monticello tools.
Maybe the length is a bit ugly and by convention we can condense it a
bit. Does that timestamp in the filename need to be human decodable?
YY-->alpha character, e.g. 2016-->F (these sort after existing numeric numbers)
MM-->hex e.g. Jan-->1 Oct-->A Dec-->C
DD-->extended hex 1-->1, 16-->F, 30-->T
hh-->extended hex e.g. 1-->1, 16-->F, 23-->M
mm-->standard number
ss-->divide by 2 then extended hex, e.g. 8-->4, 32-->F
Today 2016-06-30 23:15:32 --> F6TM15F
e.g. Collections-Native.BenComan.F6TM15F.mcz
Ben,
the "unique version number" was in reference to the current scheme of incrementing the
version number ... the truth is that I don't think it is necessary to "guarantee a unique
version number" for Monticello purposes ... it is sufficient to take the latest version number
or the package from the set of: the image and repositories in repository group... which is the
technique that was used for years ...
The bug in MCLazyVersionInfo is that it is scanning all repositories connected
to the image, when it is sufficient to scan the repositories in the working
copy repository group to get a reasonably unique version number ...
Can this be fixed easily?
I suspect it is easy to fix... Just make the lazy version info aware of
the repository group of the working copy.
Thierry
thanks, Norbert
Dale
