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