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