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 cheers -ben
