sapling/tests/test-lock-badness.t

#require unix-permissions no-root no-windows

Prepare

  $ hg init a
  $ echo a > a/a
  $ hg -R a ci -A -m a
  adding a

  $ hg clone a b
  updating to branch default
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved

One process waiting for another

  $ cat > hooks.py << EOF
  > import time
  > def sleepone(**x): time.sleep(1)
  > def sleephalf(**x): time.sleep(0.5)
  > EOF
  $ echo b > b/b
  $ hg -R b ci -A -m b --config hooks.precommit="python:`pwd`/hooks.py:sleepone" > stdout &
  $ hg -R b up -q --config hooks.pre-update="python:`pwd`/hooks.py:sleephalf"
  waiting for lock on working directory of b held by '*:*' (glob)
  got lock after ? seconds (glob)
  warning: ignoring unknown working parent d2ae7f538514!
  $ wait
  $ cat stdout
  adding b

Pushing to a local read-only repo that can't be locked

  $ chmod 100 a/.hg/store

  $ hg -R b push a
  pushing to a
  searching for changes
  abort: could not lock repository a: Permission denied
  [255]

  $ chmod 700 a/.hg/store
tests: change some #ifs to #requires 2014-08-06 20:53:08 +04:00			`#require unix-permissions no-root no-windows`
localrepo: give a sigh of relief when getting lock after waiting for it A message like this was sometimes shown when pushing: remote: waiting for lock on repository foo held by 'mercurial:20858' That could scare users, making them wonder whether the push actually succeeded. To mitigate that fear, issue an additional "warning" such as: got lock after 2 seconds The return value from lock.lock.lock() was unused - instead we return the delay. This also adds the first test coverage for waiting for locks. 2014-02-06 04:55:09 +04:00
			`Prepare`

tests: unify test-lock-badness 2010-08-26 14:41:00 +04:00			`$ hg init a`
			`$ echo a > a/a`
			`$ hg -R a ci -A -m a`
			`adding a`

			`$ hg clone a b`
			`updating to branch default`
			`1 files updated, 0 files merged, 0 files removed, 0 files unresolved`

localrepo: give a sigh of relief when getting lock after waiting for it A message like this was sometimes shown when pushing: remote: waiting for lock on repository foo held by 'mercurial:20858' That could scare users, making them wonder whether the push actually succeeded. To mitigate that fear, issue an additional "warning" such as: got lock after 2 seconds The return value from lock.lock.lock() was unused - instead we return the delay. This also adds the first test coverage for waiting for locks. 2014-02-06 04:55:09 +04:00			`One process waiting for another`

			`$ cat > hooks.py << EOF`
			`> import time`
			`> def sleepone(**x): time.sleep(1)`
			`> def sleephalf(**x): time.sleep(0.5)`
			`> EOF`
tests: unify test-lock-badness 2010-08-26 14:41:00 +04:00			`$ echo b > b/b`
localrepo: give a sigh of relief when getting lock after waiting for it A message like this was sometimes shown when pushing: remote: waiting for lock on repository foo held by 'mercurial:20858' That could scare users, making them wonder whether the push actually succeeded. To mitigate that fear, issue an additional "warning" such as: got lock after 2 seconds The return value from lock.lock.lock() was unused - instead we return the delay. This also adds the first test coverage for waiting for locks. 2014-02-06 04:55:09 +04:00			$ hg -R b ci -A -m b --config hooks.precommit="python:`pwd`/hooks.py:sleepone" > stdout &
			$ hg -R b up -q --config hooks.pre-update="python:`pwd`/hooks.py:sleephalf"
			`waiting for lock on working directory of b held by ':' (glob)`
tests: match time by a glob to fix intermittent failures of test-lock-badness.t Sometimes the lock was a bit slower and took 2 seconds. Do not fail the test by this. The glob ? matches from 0 to 9 seconds, which should be enough safety. 2014-03-05 17:03:08 +04:00			`got lock after ? seconds (glob)`
localrepo: give a sigh of relief when getting lock after waiting for it A message like this was sometimes shown when pushing: remote: waiting for lock on repository foo held by 'mercurial:20858' That could scare users, making them wonder whether the push actually succeeded. To mitigate that fear, issue an additional "warning" such as: got lock after 2 seconds The return value from lock.lock.lock() was unused - instead we return the delay. This also adds the first test coverage for waiting for locks. 2014-02-06 04:55:09 +04:00			`warning: ignoring unknown working parent d2ae7f538514!`
			`$ wait`
			`$ cat stdout`
tests: unify test-lock-badness 2010-08-26 14:41:00 +04:00			`adding b`

localrepo: give a sigh of relief when getting lock after waiting for it A message like this was sometimes shown when pushing: remote: waiting for lock on repository foo held by 'mercurial:20858' That could scare users, making them wonder whether the push actually succeeded. To mitigate that fear, issue an additional "warning" such as: got lock after 2 seconds The return value from lock.lock.lock() was unused - instead we return the delay. This also adds the first test coverage for waiting for locks. 2014-02-06 04:55:09 +04:00			`Pushing to a local read-only repo that can't be locked`

tests: unify test-lock-badness 2010-08-26 14:41:00 +04:00			`$ chmod 100 a/.hg/store`

			`$ hg -R b push a`
			`pushing to a`
localrepo: add unbundle support Localrepo now supports the unbundle method of pushing changegroups. We plan to use the unbundle call for bundle2 so it is important that all peers supports it. The `peer.unbundle` and `peer.addchangegroup` code path have small difference so cause some test output changes. None of those changes seems problematic. 2014-04-05 04:50:44 +04:00			`searching for changes`
tests: unify test-lock-badness 2010-08-26 14:41:00 +04:00			`abort: could not lock repository a: Permission denied`
tests: add exit codes to unified tests 2010-09-17 02:51:32 +04:00			`[255]`
tests: unify test-lock-badness 2010-08-26 14:41:00 +04:00
			`$ chmod 700 a/.hg/store`