On Thu, Jun 30, 2016 at 7:26 AM, Dale Henrichs <dale.henri...@gemtalksystems.com> wrote: > > > 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 > ... > > Dale >
If changing that is sufficient, then cool. My idea was just covering Law Of Unintended Consequence ;) cheers -ben
