Trying to load a fork of a baseline after loading the original fails with error MetacelloConflictingProjectError

[macta]

If you load a metacello script in a pharo image (but assume this applies to all smalltalks) and then decide to fork that project, and you want to reload the fork - metacello insists on loading the original repository because the MetacelloProjectRepository>>registrationFor: aMetacelloProjectRegistration ifPresent: presentBlock ifAbsent: absentBlock
uses only the basline name to distinguish what to load

e.g. self baselineRegistry at: spec className ifPresent: [ :existing | ^ presentBlock value: existing ]

This means you can't easily load a different variant of the baseline. The key to the registroy should be name+repo name.

[macta]

Actually I wonder if using #onConflictUseIncoming ; is a solution to this? Its not really a conflict - but I think the intent is to use the incoming version - perhaps someone might comment on this and advise.

[dalehenrich]

Just a note, but I don't think Pharo uses this project for it's Metacello code ... they "forked" Metacello several years ago and I'm not sure anyone else from the Pharo community is paying attention :)

[macta]

ah - well that makes 2 problems... oh dear

[dalehenrich]

... well I think I can answer the original question ... conflicts are conflicts in the Metacello specification so switching repositories is a "conflict" you have two choices when trying to force the use of a particular repository ...
You can #lock a repository:

  Metacello new
    baseline: 'FileTree';
    repository: 'filetree://', projectDirectory, '/filetree/repository';
    lock.

This lock should force the FileTree project to be loaded from projectDirectory, '/filetree/repository ... This is the preferable solution ... you will get lock notifications like the conflict notifications that can be honored ... I don't have an image with Metacello at my fingertips ... so I forget the default handling and messages that are used... you have the option of breaking locks as well ... The lock is something that should be "permanent". Conflicts are temporary ...

Conflicts are intended to let you know when an attempt is made to load from a different repository than you are using ... locks are intended for you to state your preference and be done with it ...

The thing I don't know is how Pharo deals with locks in the presence of Iceberg or what the current state of the Pharo Metacello implementation is ...