Doru,
That is a good idea. It might also make sense from a Pharo perspective to have
a global fallback defined. I am expecting that the mechanisms that we come up
with will be useful for individual projects as well as Pharo overall, so
building in flexibility at load time (instead of embedded
Hi all
I would like that we have a discussion about how do we put in place an
infrastructure to make sure that we can get
metacello configuration working in 3/5 years from now.
I think that there are two scenarios:
MyProject
==
in my project I used metacello and I publish a config and if
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 packages
moved by Lukas.
We have a problem with the packages referenced by a ConfigurationOfXXX.
The can disappear anytime. The repository can disappear anytime.
So I
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 packages
moved by Lukas.
We have a problem with the packages referenced by a ConfigurationOfXXX.
The can disappear anytime. The
make sure that we can get metacello configuration working in 3/5 years from
now.
We should also think about
- mirroring. Currently in Metacello you give the repo hard coded in the
baseline.
Maybe it would be better to have an alias there and define the repo
elsewhere (for instance
El mar, 23-02-2010 a las 14:12 +0100, Göran Krampe escribió:
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 on
the SqueakMap server.
In that way it was meant to handle original URLs going stale or
Hi, I am very interested in the whole configuration management, metacello,
monticello, public/private repository, project, library/package, object,
project, environment, release, version stuff ... some clarity around is
badly needed.
My first contact with the whole Squeak/Pharo packages and
and with that I did not mean to use those other DVCS but maybe take ideas
from them :)
--
View this message in context:
http://n4.nabble.com/Metacello-How-to-make-sure-that-we-will-be-able-to-load-in-3-years-from-now-tp1565830p1566007.html
Sent from the Pharo Smalltalk mailing list archive at
and with that I did not mean to use those other DVCS but maybe take ideas
from them :)
This is not a problem any DVCS tackles. Rather take ideas of package
management systems like aptitude, rpm, portage, fink, ... As you see
in all such system, they ship the code (binary or source) together
neat!
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 packages
moved by Lukas.
We have a problem with the packages referenced by a ConfigurationOfXXX.
The can disappear anytime. The repository can disappear
On Feb 23, 2010, at 2:25 PM, Torsten Bergmann wrote:
make sure that we can get metacello configuration working in 3/5 years from
now.
We should also think about
- mirroring. Currently in Metacello you give the repo hard coded in the
baseline.
Maybe it would be better to have
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
Perhaps Gofer can be provided with a secondary repository location in the
case when the primary repository fails.
Yes, it can. You just specify multiple repositories and it will use
them all. If you tell Gofer to #disableRepositoryErrors then it will
silently ignore repositories that are not
- Lukas Renggli reng...@gmail.com wrote:
| Perhaps Gofer can be provided with a secondary repository location
| in the case when the primary repository fails.
|
| Yes, it can. You just specify multiple repositories and it will use
| them all. If you tell Gofer to #disableRepositoryErrors
What if use redudancy features of Internet itself? As you know the
Internet was designed to withstand a nuclear attack, with a lot of
redudant features, which we can explore to harden the Smalltalk
infracture as well.
In the similar ways as guyss like Google do. You know, they have always
a
Hi Dale,
I believe the original problem is that you do not know upfront about
where the actual files will be. In this case, perhaps the easiest
solution is to provide some scripting facility to provide a repository
mapping that should could be modified at loading time, and not be
stored
16 matches
Mail list logo
