Design for new lock extension

Dominik Psenner dpsenner at gmail.com
Tue Mar 22 09:27:14 CDT 2011


1] I would expect that hg lock and hg unlock synchronizes itself with the
"lock repository", is that true?

2] Why should hg push unlock files? One could want to share a partially
finished work with one working oversea without releasing the lock.

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

> 
>     * 'hg lock FILE --steal': If the file is unmodified, up to date and
>       locked by someone else, transfer the lock to the user and send an
>       email notifying the original user. Otherwise, fail with an
>       appropriate message.
> 
>     * 'hg unlock FILE': If the file is unmodified and locked by the
>       user, unlock the file. Otherwise, fail with an appropriate
>       message.
> 
>     * 'hg unlock FILE --force': If the file is locked by someone else,
>       unlock the file and send an email notifying the original user.
>       Otherwise, fail with an appropriate message.
> 
>     * '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.
> 
>     * '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?

> 
>     * 'hg update': New versions of files are handled as follows:
> 
>           o modified, unlocked files for which locking is mandatory:
>             Local versions are overwritten by other versions using the
>             internal:other merge tool and listed as such in the output.
> 
>           o modified, locked files: Other versions are created using the
>             internal:dump merge tool. Then the user resolves. (This case
>             should only occur if a lock has been stolen or an unlock
>             forced. Otherwise the lock policy ensures that merges of
>             files for which locking is mandatory are trivial.)
> 
>           o All other files are handled as normal.
> 
> Please let me know your thoughts!
> 
> --
> Martin Geisler
> 
> aragost Trifork
> Professional Mercurial support
> http://aragost.com/en/services/mercurial/blog/
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel



More information about the Mercurial-devel mailing list