annotate contrib/dockerlib.sh @ 24992:7df090c9c9fe

localrepo: use changelog.hasnode instead of self.__contains__

Before this patch, releasing the store lock implies the actions below, when
the transaction is aborted:

  1. "commithook()" scheduled in "localrepository.commit()" is invoked
  2. "changectx.__init__()" is invoked via "self.__contains__()"
  3. specified ID is examined against "repo.dirstate.p1()"
  4. validation function is invoked in "dirstate.p1()"

In subsequent patches, "dirstate.invalidate()" invocations for
discarding changes are replaced with "dirstateguard", but discarding
changes by "dirstateguard" is executed after releasing the store lock:
resources are acquired in "wlock => dirstateguard => store lock" order,
and are released in reverse order.

This may cause that "dirstate.p1()" still refers to the changeset to be
rolled-back at (4) above: pushing multiple patches by "hg qpush" is
a typical case.

When releasing the store lock, such changesets are:

  - not contained in "repo.changelog", if it is reloaded from
    ".hg/00changelog.i", as that file was already truncated by
    "transaction.abort()"

  - still contained in it, otherwise
    (this "dirty read" problem is discussed in "Transaction Plan"
     http://mercurial.selenic.com/wiki/TransactionPlan)

Validation function shows "unknown working parent" warning in the
former case, but reloading "repo.changelog" depends on the timestamp
of ".hg/00changelog.i". This causes occasional test failures.

In the case of scheduled "commithook()", it just wants to examine
whether "node ID" of committed changeset is still valid or not. Other
examinations implied in "changectx.__init__()" are meaningless.

To avoid showing the "unknown working parent" warning irregularly, this
patch uses "changelog.hasnode()" instead of "node in self" to examine
existence of committed changeset.

#!/bin/sh -eu

# This function exists to set up the DOCKER variable and verify that
# it's the binary we expect. It also verifies that the docker service
# is running on the system and we can talk to it.
function checkdocker() {
  if which docker.io >> /dev/null 2>&1 ; then
    DOCKER=docker.io
  elif which docker >> /dev/null 2>&1 ; then
    DOCKER=docker
  else
    echo "Error: docker must be installed"
    exit 1
  fi

  $DOCKER -h 2> /dev/null | grep -q Jansens && { echo "Error: $DOCKER is the Docking System Tray - install docker.io instead"; exit 1; }
  $DOCKER version | grep -q "^Client version:" || { echo "Error: unexpected output from \"$DOCKER version\""; exit 1; }
  $DOCKER version | grep -q "^Server version:" || { echo "Error: could not get docker server version - check it is running and your permissions"; exit 1; }
}

# Construct a container and leave its name in $CONTAINER for future use.
function initcontainer() {
  [ "$1" ] || { echo "Error: platform name must be specified"; exit 1; }

  DFILE="$ROOTDIR/contrib/docker/$1"
  [ -f "$DFILE" ] || { echo "Error: docker file $DFILE not found"; exit 1; }

  CONTAINER="hg-dockerrpm-$1"
  DBUILDUSER=build
  (
    cat $DFILE
    if [ $(uname) = "Darwin" ] ; then
        # The builder is using boot2docker on OS X, so we're going to
        # *guess* the uid of the user inside the VM that is actually
        # running docker. This is *very likely* to fail at some point.
        echo RUN useradd $DBUILDUSER -u 1000
    else
        echo RUN groupadd $DBUILDUSER -g `id -g`
        echo RUN useradd $DBUILDUSER -u `id -u` -g $DBUILDUSER
    fi
  ) | $DOCKER build --tag $CONTAINER -
}