On 11/10/17 1:14 AM, Peter Uhnák wrote:
Hi Dale,
I am aware of locking, but that requires I know all the recursive
dependencies so I can lock them before loading the project itself.
I can do that locally (and I've done it in the past), but I cannot
easily force that upon users. This also applies for SmalltalkCI which
will just try to load the baseline and will run into the conflict (the
conflict pasted in the first mail actually comes from SCI).
Ah .... well getting load conflicts is a feature in that case:)
In that case you are trying to load "two different" projects with the
same name from incompatible repositories and someone has to decide ...
the problem partially likes in the fact that the maintainers of project
X haven't committed to a primary repository ...
The other part of the problem has to do with being able to specify
conflict handling in SmalltalkCI ... the Metacello load command allows
you to programmatically decide which side of the conflict wins during
the load, but the SCIMetacelloLoadSpec hasn;t quite gotten to the point
where the conflct resolution has been exposed
At the end of the day, the maintainers of project X need to make up
their minds and SmalltalkCI needs to expose the conflict resolution api
for Metacllo ...
Dale
Thanks,
Peter
On Thu, Nov 9, 2017 at 11:17 PM, Dale Henrichs
<[email protected]
<mailto:[email protected]>> wrote:
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
<https://www.youtube.com/watch?v=Ejmqs0xLvSk&list=PLCGAAdUizzH06AkHg6_UxZ6QZBgz84yAc&index=25>
[2] https://www.youtube.com/watch?v=QshDlH1ADZQ
<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
<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
