Peter,

Metacello locks are supposed to address this kind of problem ... at this point in time, any project that is loaded from a git project should be 'locked' using a Metacello lock.

The lock means that any request to load that project will use the locked version instead of the version specified in the configuration/baseline.

A lock can be applied to a project without actually loading the project ...

Presuming that you have a preference towards using the local git repository for project X, then you can lock project X with a reference to the local git repository:

�� Metacello new

������ project: 'X';

������ repository: '......';

������ lock.

... and from this point on any attempt by Metacello to load project X will load from the local git repository ...

Once you have a local clone of a project it is very likely that you will want to share that repository amongst many of your local pharo projects and to do that with Metacallo you need to lock those projects in each of your images, including new images ...

This can lead to a lot of locking ... I talk about the approach that I use in tODE to address this problem in two Smalltalks talks [1] and [2]...

Dale

[1] https://www.youtube.com/watch?v=Ejmqs0xLvSk&list=PLCGAAdUizzH06AkHg6_UxZ6QZBgz84yAc&index=25

[2] https://www.youtube.com/watch?v=QshDlH1ADZQ

On 11/9/17 12:21 PM, Peter Uhn��k wrote:

Hi,

as people are increasingly starting to move to git and baselines, it is becoming more and more common that there are loading issues:

A depends on B and C

B depends on ConfigurationOfX

C depends on BaselineOfX

and then loading fails on

MetacelloConflictingProjectError: Load Conflict between existing
BaselineOfStateSpecs [baseline] from github://dionisiydk/StateSpecs:v2.4.x and ConfigurationOfStateSpecs stable from http://www.smalltalkhub.com/mc/dionisiy/StateSpecs/main

I imagine that this will become more and more common.

Can this be resolved in some automated fashion?

Thanks,
Peter