Design for new lock extension

[Martin Geisler]

"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.

> 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.

>> -----Original Message-----
>> From: mercurial-devel-bounces at selenic.com [mailto:mercurial-devel-
>> bounces at selenic.com] On Behalf Of Martin Geisler
>> Sent: Tuesday, March 22, 2011 12:24 PM
>> To: Mercurial Developers
>> Subject: Design for new lock extension
>> 
>> 4. Commands
>> 
>> Note: Some commands can take multiple files as argument. The
>> operation is not expected to be atomic (that is, 'hg lock', for
>> example, can lock some files and fail to lock others). The command
>> fails overall if the operation fails for an least one file. We ignore
>> this complication in the description of the commands.
>> 
>>     * 'hg locks': List the locks in the lock repository. The fields and
>>       order are: user email, branch, how long the file has been locked,
>>       last commit time, path.
>> 
>>     * 'hg lock FILE': If the file is unmodified, up to date and not
>>       locked, lock the file. Otherwise, fail with an appropriate
>>       message.
>
> Lock should notify the parent repository about the new lock so that
> others are informed about the lock.

Definitely, this sends a request to the lock repository with the pushkey
protocol. On the lock repository, the extension appends a line to the
.hg/locks file in the lock repository.

>>     * 'hg commit': Ignores modified, unlocked files for which locking is
>>       mandatory; outputs a warning message for each such file. Operates
>>       like normal on other files. The lock is refreshed in the lock
>>       repository for each locked file that was part of the commit.

This also communicates with the central server to refresh the lock
timestamp. The lock timestamp is not essential, but 'hg locks' can use
them to show you how long ago a locked file was last committed to.

>>     * 'hg push': Unlocks locked files that are part of the revisions to
>>       be pushed.
>
> This would mean that locks are never published to the central and
> others never see my locks, or am I wrong?

The idea is to only store the locks on the central server.

-- 
Martin Geisler

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