tests/blacklists/inotify-failures
author Wagner Bruna <wbruna@softwareexpress.com.br>
Mon, 12 Mar 2012 17:02:45 -0300
branchstable
changeset 16252 cf17e76be4dd
parent 10300 c437745f50ec
child 17482 3afb61810680
permissions -rw-r--r--
strip: enhance repair.strip to receive a list of nodes (issue3299) Originally, mq.strip called repair.strip a single rev at a time. repair.strip stores in a backup bundle any revision greater than the revision being stripped, strips, then restores the backup with repo.addchangegroup. So, when stripping revisions on more than one topological branch, some could end up being restored from the backup bundle, only to be later removed by a subsequent repair.strip call. But repo.addchangegroup calls hooks for all those restore operations. And 9df9444e96ec changed it to delay all hook calls until the repository lock were released - by mq.strip, after stripping all revisions. Thus, the hooks could be called over revisions already removed from the repository at that point. By generating the revision lists at once inside repo.strip, we avoid calling addchangegroup for temporary restores. Incidentally, this also avoids creating many backup files for a single strip command.

# When --inotify is activated, help output and config changes:
test-debugcomplete
test-empty
test-fncache
test-globalopts
test-help
test-hgrc
test-inherit-mode
test-qrecord
test-strict

# --inotify activates de facto the inotify extension. It does not play well
# with inotify-specific tests, which activate/desactivate inotify at will:
test-inotify
test-inotify-debuginotify
test-inotify-dirty-dirstate
test-inotify-issue1208
test-inotify-issue1371
test-inotify-issue1542
test-inotify-issue1556
test-inotify-lookup