> Am 30.06.2016 um 01:26 schrieb Dale Henrichs > <[email protected]>: > > > >> On 6/29/16 3:44 PM, Ben Coman wrote: >> On Thu, Jun 30, 2016 at 3:04 AM, Dale Henrichs >> <[email protected]> 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?
thanks, Norbert > Dale >
