Peter, I think that perhaps you are using an older version of Metacello. At one time, I recommended that locks be handled like the following: Metacello registry baseline: 'Example'; onConflict: [ :ex :existing | existing locked ifTrue: [ ex useIncoming ]. ex pass ]; onLock: [ :ex | ex honor ]; load: 'Tests'. Note the dual blocks where the onConflict block sends #useIncoming (equivalent to #allow) and the onLock: block uses #honor (which is equivalent to #disallow). This was way too complicated In subsequent releases, the api was fine-tuned such that: a) locks are honored by default with a Warning signalled b) an onConflict: block is no longer required for handling locks ... the default onConflict: handler does a #useIncoming Therefore with the latest version of Metacello the following load expression should honor locks: "BORM Editor" Metacello new baseline: 'BormEditor'; repository: 'github://dynacase/borm-editor/repository'; load. The fact that your load expression is not honoring the lock implies that you are using an older version of Metacello, so you can either upgrade Metacello[1] (the expression works for Pharo3.0 and later version) or add an onLock: block to #honor locks ... Dale [1] https://github.com/dalehenrich/metacello-work#pharo30 On 05/31/2015 11:16 PM, Peter Uhnák wrote:
Hi,
I've encountered what seems to be Metacello ignoring locking with Git.
if I do something like
~~~~~~~~~~~~~~~` "DynaCASE" Metacello new baseline: 'DynaCASE'; repository: 'github://dynacase/dynacase:peter-dev/repository'; lock.
"BORM Editor" Metacello new baseline: 'BormEditor'; repository: 'github://dynacase/borm-editor/repository'; onConflict: [ :ex | ex allow ]; load ~~~~~~~~~~~~~~~
then the second command will load the "master" branch instead of the expected "peter-dev" without any complains. My assumption is that it compares only the base url and not also the branch.
Thanks, Peter