lock: while releasing, unlink lockfile even if the release function throws Consider a hypothetical bug in the release function that causes it to raise an exception. Also consider the bisect command, which saves its state in a finally clause. Saving the state requires acquiring the wlock. If we don't unlink the lockfile when the exception is thrown, we'll try to acquire the wlock again. We're going to try and acquire a lock again while our old lockfile is on disk. The PID on disk is our own, and of course we're still running, so we won't take over the lock. Hence we'll be stuck waiting for a lock that we left behind ourselves. To avoid this, always unlink the lockfile. This preserves the invariant that self.held > 0 is equivalent to the lockfile existing on disk.

     1

all()

     2

draft()

     3

::tip

     4

draft() and ::tip

     5

::tip and draft()

     6

0::tip

     7

roots(0::tip)

     8

author(lmoscovicz)

     9

author(mpm)

    10

author(lmoscovicz) or author(mpm)

    11

author(mpm) or author(lmoscovicz)

    12

tip:0

    13

max(tip:0)

    14

min(0:tip)

    15

0::

    16

min(0::)

    17

# those two `roots(...)` inputs are close to what phase movement use.

    18

roots((tip~100::) - (tip~100::tip))

    19

roots((0::) - (0::tip))

    20

::p1(p1(tip))::

    21

public()

    22

:10000 and public()

    23

draft()

    24

:10000 and draft()

    25

max(::(tip~20) - obsolete())

    26

roots((0:tip)::)

    27

(not public() - obsolete())

    28

(_intlist('20000\x0020001')) and merge()

    29

parents(20000)

    30

(20000::) - (20000)

    31

# The one below is used by rebase

    32

(children(ancestor(tip~5, tip)) and ::(tip~5))::