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
