[Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now
dale.henrichs at gemstone.com
Tue Feb 23 13:48:44 EST 2010
I like the notion of a secondary repository for packages. It is absolutely necessary to protect us from a catastrophic failure with any one of the SqueakSource repositories.
Perhaps Gofer can be provided with a secondary repository location in the case when the primary repository fails.
With this kind of approach, the metacello configurations can continue to reference the primary development repository, in this way we might just be able to have our cake and eat it too:) The Pharo secondary repository would protect users from repository volatility and package volatility ... Once a version is published in Pharo you can count of being able to load that version over time.
This secondary repository could be maintained by periodically scanning the Pharo configurations and copying the referenced packages from the primary repository to a known secondary repository (this repository could just be done with Apache file access since a fancy UI for the secondary repository isn't essential).
Having code and processes in place means that individuals can reuse the code and process to maintain their own secondary repository for their own production environment.
I have code that does most of what is needed, as I use this process at GemStone for archiving the configurations and mcz packages in our company source code control system.
----- "Göran Krampe" <goran at krampe.se> wrote:
| Miguel Enrique Cobá Martinez wrote:
| > El mar, 23-02-2010 a las 11:14 +0100, stephane ducasse escribió:
| > I was thinking about this problem yesterday in the light of the
| > moved by Lukas.
| > We have a problem with the packages referenced by a
| > The can disappear anytime. The repository can disappear anytime.
| > So I thought that we need a dedicated hosting server where:
| > - We have all the ConfigurationOfXXX (in the MetacelloRepository
| > just as now)
| > - We copy there *all* the packages that conform a giver
| > ConfigurationOfXXX>>versionXX: from the original repo to this
| > repo.
| > - There is *no way* to delete anything. This is a *write only, read
| > always, delete never* repository.
| Sidenote: SqueakMap actually caches all URLs used for versions and if
| the original URL fails an SHA check it falls back on the cached file
| the SqueakMap server.
| In that way it was meant to handle original URLs going stale or
| regards, Göran
| Pharo-project mailing list
| Pharo-project at lists.gforge.inria.fr
More information about the Pharo-dev