On Fri, Aug 8, 2014 at 3:54 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 08 Aug 2014, at 06:16, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Ben and Sean,
After a bit more thought, I believe that it should be okay to make copies, but there does need to be a single primary repository where the correct and latest configuration can be found.
Putting copies of configurations into repositories to make project discovery easier is a good use of copies. Copies are also useful when creating mirror repos....
But one must be able to determine the location of the canonical repository for the configuration.
If the configuration were always co-located with the packages then it would relatively easy to figure out where to find the newest and 'correctest' configuration.
The canonical location should ALWAYS be used in project references.
But can't Metacello help there ?
I mean, each configuration, no matter where it is copied/located is the same and knows its canonical repository, right ?
So all that is needed is a kind of double-check, or following the reference.
BTW, doesn't Metacello not do some latest version checking already ?
Sven,
In a project reference, the developer specifies the repository from which the configuration should be loaded: spec project: 'Zinc Project' with: [ spec versionString: #'stable'; className: 'ConfigurationOfZincHTTPComponents'; repository: 'http://mc.stfx.eu/ZincHTTPComponents' ]. In the above case, the canonical repository for Zinc is being used, but a developer can use a different repository like http://squeaksource.com/MetacelloRepository. Metacello's job is to do what the developer specifies. The developer may have perfectly good reasons for specifying a different location than the canonical repository: - critical bug fix to configuration, but no write access to canonical repo - private fork of project ... - etc. Metacello cannot second guess the developer when it comes to loading packages:) Sean is referring to the fact that some configurations are not present in the repository where the packages are located and they should be. Also there are cases where the generic *MetacelloRepository* is used in a project reference when the canonical location should be. Dale