Design for new lock extension

Martin Geisler mg at aragost.com
Wed Mar 23 03:53:39 CDT 2011


"Dominik Psenner" <dpsenner at gmail.com> writes:

>> -----Original Message-----
>> From: Martin Geisler [mailto:mg at aragost.com]
>> Sent: Tuesday, March 22, 2011 4:38 PM
>> To: Dominik Psenner
>> Cc: 'Mercurial Developers'
>> Subject: Re: Design for new lock extension
>> 
>> "Dominik Psenner" <dpsenner at gmail.com> writes:
>> 
>> > 1] I would expect that hg lock and hg unlock synchronizes itself with
>> > the "lock repository", is that true?
>> 
>> Yeah -- the client holds no state by itself. The lock and unlock
>> commands talk with the lock repository every time. So lock and unlock
>> are an interface to editing a file with the filenames of locked files on
>> the server.
>
> Sounds neat. Of course this works only as long as you're connected to
> the lock repository. I just worry that the lock is a mainly a:
>
> Hg pull
> Hg up
> Hg commit
> Hg push
>
> and thus no atomar operation. It should be safe as long as push can
> fail with some kind of error like "sorry, this lock has now
> $SOMEONE_ELSE".

The idea is that you do

  $ hg pull
  $ hg update
  $ hg lock budget.xls
  (work on the budget...)
  $ hg commit -m 'Budget for Q2'
  (work some more on the budget...)
  $ hg commit -m 'Budget for Q3'
  $ hg push  # also releases the lock

If someone else tries to lock the file after you locked it, then they
will be told that they should wait until you have released the lock.

>> > 2] Why should hg push unlock files? One could want to share a
>> > partially finished work with one working oversea without releasing
>> > the lock.
>> 
>> Hmm, yeah, perhaps... I think that was just to make the workflow easy
>> for my client: lock, work..., push -- no forgotten locks.
>
> One can discuss what makes more sense:
>
> Hg push --keep-lock
>
> Or
>
> Hg push --remove-locks

Yeah, I see what you mean.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/en/services/mercurial/blog/


More information about the Mercurial-devel mailing list