Design for new lock extension

[Dominik Psenner]

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

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

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