Thanks, I'm glad Pharo will adopt too, since having common MC API's between Squeak and Pharo will make life easier.
I only posted the latest versions, there there are 8 or 10 interim ancestor versions which I will copy to trunk in a few days. - Chris On Wed, Mar 9, 2011 at 2:55 AM, Stéphane Ducasse <[email protected]> wrote: > thanks > > If somebody want to get the code and prepare it for pharo this will help. > > Stef > > > > On Mar 8, 2011, at 10:38 PM, Janko Mivšek wrote: > >> >> >> -------- Original Message -------- >> Subject: [squeak-dev] sustainable Monticello >> Date: Tue, 8 Mar 2011 15:33:19 -0600 >> From: Chris Muller <[email protected]> >> Reply-To: [email protected], The general-purpose Squeak developers >> list <[email protected]> >> To: squeak dev <[email protected]> >> >> This will probably be a long post, but I would like to tell you about >> the Monticello upgrades I'm about to move to the trunk. >> >> Monticello has several repository types: >> >> MCRepository #('creationTemplate' 'storeDiffs') >> MCDictionaryRepository #('description' 'dict') >> MCFileBasedRepository #('cache' 'allFileNames') >> MCDirectoryRepository #('directory') >> MCCacheRepository >> #('packageCaches' 'seenFiles') >> MCSubDirectoryRepository #() >> MCFtpRepository #('host' 'directory' >> 'user' 'password' 'connection') >> MCHttpRepository #('location' 'user' >> 'password' 'readerCache') >> MCSMCacheRepository #('smCache') >> MCGOODSRepository #('hostname' 'port' >> 'connection') >> MCWriteOnlyRepository #() >> MCSMReleaseRepository #('packageName' >> 'user' 'password') >> MCSmtpRepository #('email') >> >> but MCFileBasedRepository is the one that has been given all of the >> focus, the other repository types have been ignored over the years. >> MCHttpRepository is the one that interfaces with SqueakSource, and >> MCDirectoryRepository are pretty much the only types being used. >> >> I know this because external users of MCRepository API, like the >> Repository-browser tools and MC-Configurations and Installer; these >> are all using API's that are specific to MCFileBasedRepository - not >> generally understood by the other repository-types or the abstract API >> in MCRepository. >> >> This is worthy of concern because of the access-limitations of a >> MCFileBasedRepository. Unlike a MCGOODSRepository, for example, a >> file-system-based repository cannot efficiently meet the demands of >> being a MCRepository without, at some points, needing to enumerating >> ALL version names (files) in its file-system location. >> >> As the number of versions in a repository reaches 1-million and >> beyond, performance will grind to a halt due to the number of files >> that must be constantly downloaded into RAM (another area of >> unscalability and unsustainability related to FileBased Repository's). >> A purging of old versions could be done, but a philosophy of >> Monticello, from the outset, has been that repository's are intended >> to contain "all" of version history. >> >> I have therefore reworked the MCRepository API's and external tools to >> talk using only an API that is understood by any repository that >> implements the methods identified as #subclassResponsibility in >> MCRepository. This minimally-required API is now: >> >> #allPackageNames - answer a list of package names in this repository. >> #basicStoreVersion: - add a Version to this repository. >> #includesVersionNamed: - does a version with this name exist in this >> repository? >> #versionNamed: - answer the first Version object with the given name. >> #versionNamesForPackageNamed: - answer the version names for the >> given package name. >> #versionWithInfo:ifAbsent: - answer the Version object with the >> given unique VersionInfo >> >> In deference to the limitations of FileBasedRepository's, we only ask >> for the _names_ of things rather than the whole object, because the >> names are all that is needed to satisfy tool requirements, except in >> cases where we need a single Version object (like loading). FileBased >> cannot access the Version objects quickly, just the (file)names (incl. >> author & version-number). >> >> During the process of this refactoring, I was able to signficantly >> improve the coherence of the code. It was really, really bad in some >> areas. >> >> I've also verified the viability of this API by updating >> MCMagmaRepository, and demonstrating using Magma as a >> totally-sustainable and scalable MC repository. Employing a >> Magma-based Repository also affords some additional benefits, which I >> will describe in a separate follow-up mail. >> >> I think SqueakSource will eventually have to change to something more >> scalable. At least now we have have a viable alternative, and with >> much cleaner MC code in the process. >> >> Please load my latest versions of Monticello, >> MonticelloConfigurations, Installer and Tests from the Inbox and let >> me know if you experience any issues. You should not see any >> difference in day-to-day operations. >> >> - Chris >> >> >> > > >
