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
