facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-07 23:38:50 +03:00
Code Issues Projects Releases Wiki Activity
3ba5dbc55e
sapling/tests/test-blackbox.t

187 lines
5.6 KiB
Perl
Raw Normal View History

blackbox: tests for the blackbox extension A few tests to cover the blackbox extension. Covers commands, hooks, and incoming changes.
2013-02-10 01:35:30 +04:00
setup
$ cat >> $HGRCPATH <<EOF
> [extensions]
> blackbox=
tests: move mock blackbox extension into own file Having all blackbox log testing in test-blackbox.t isn't scalable. Move the mock blackbox extension into its own file so we can start to move blackbox logging into other tests.
2015-04-13 16:36:33 +03:00
> mock=$TESTDIR/mockblackbox.py
blackbox: add backup bundle paths to blackbox logs Writes the backup bundle paths to the blackbox so it's easy to see which backup bundle is associated with which command when you are debugging an issue. Example output: 2013/03/13 10:39:56 durham> strip tip 2013/03/13 10:39:59 durham> saved backup bundle to /data/users/durham/www-hg/.hg/strip-backup/e5fac262363a-backup.hg 2013/03/13 10:40:03 durham> strip tip exited 0 after 7.97 seconds
2013-03-13 21:43:51 +04:00
> mq=
blackbox: tests for the blackbox extension A few tests to cover the blackbox extension. Covers commands, hooks, and incoming changes.
2013-02-10 01:35:30 +04:00
> EOF
$ hg init blackboxtest
$ cd blackboxtest
command, exit codes, and duration
$ echo a > a
$ hg add a
$ hg blackbox
blackbox: add pid to output This adds the process id to the line header for the blackbox output. This is useful for distinguishing processes when using the blackbox on a server and many processes are writing to the blackbox at once.
2015-09-07 21:31:44 +03:00
1970/01/01 00:00:00 bob (*)> add a (glob)
1970/01/01 00:00:00 bob (*)> add a exited 0 after * seconds (glob)
blackbox: flush output file descriptor Without this, when there are multiple ui views, each blackbox will have its own file handle, and the logging will be in a really bad order. Also, because of the way blackbox works, it never closes its file handles, which means the last output before exit is often lost.
2016-02-03 18:18:29 +03:00
1970/01/01 00:00:00 bob (*)> blackbox (glob)
blackbox: tests for the blackbox extension A few tests to cover the blackbox extension. Covers commands, hooks, and incoming changes.
2013-02-10 01:35:30 +04:00
incoming change tracking
blackbox: only show new heads on incoming The blackbox was logging every head after every incoming group. Now we only log the heads that have changed. Added a test. Moved the hooks test to the bottom of the file since the hooks interfer with the tests after it.
2013-02-13 23:07:01 +04:00
create two heads to verify that we only see one change in the log later
$ hg commit -ma
$ hg up null
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ echo b > b
$ hg commit -Amb
adding b
created new head
clone, commit, pull
blackbox: tests for the blackbox extension A few tests to cover the blackbox extension. Covers commands, hooks, and incoming changes.
2013-02-10 01:35:30 +04:00
$ hg clone . ../blackboxtest2
updating to branch default
blackbox: only show new heads on incoming The blackbox was logging every head after every incoming group. Now we only log the heads that have changed. Added a test. Moved the hooks test to the bottom of the file since the hooks interfer with the tests after it.
2013-02-13 23:07:01 +04:00
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo c > c
$ hg commit -Amc
adding c
blackbox: tests for the blackbox extension A few tests to cover the blackbox extension. Covers commands, hooks, and incoming changes.
2013-02-10 01:35:30 +04:00
$ cd ../blackboxtest2
$ hg pull
tests: append glob to filename output when required for windows The test failed on windows before this patch.
2013-02-24 01:07:38 +04:00
pulling from $TESTTMP/blackboxtest (glob)
blackbox: only show new heads on incoming The blackbox was logging every head after every incoming group. Now we only log the heads that have changed. Added a test. Moved the hooks test to the bottom of the file since the hooks interfer with the tests after it.
2013-02-13 23:07:01 +04:00
searching for changes
blackbox: tests for the blackbox extension A few tests to cover the blackbox extension. Covers commands, hooks, and incoming changes.
2013-02-10 01:35:30 +04:00
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
blackbox: flush output file descriptor Without this, when there are multiple ui views, each blackbox will have its own file handle, and the logging will be in a really bad order. Also, because of the way blackbox works, it never closes its file handles, which means the last output before exit is often lost.
2016-02-03 18:18:29 +03:00
$ hg blackbox -l 6
blackbox: add pid to output This adds the process id to the line header for the blackbox output. This is useful for distinguishing processes when using the blackbox on a server and many processes are writing to the blackbox at once.
2015-09-07 21:31:44 +03:00
1970/01/01 00:00:00 bob (*)> pull (glob)
tests: change blackbox test to work cross platform While it is not easy to make a file 000 on Windows, you can emulate most of the behaviors by replacing the file with a directory. Also corrects test description to properly indicate that failing to read from the log is fatal.
2016-02-03 21:15:18 +03:00
1970/01/01 00:00:00 bob (*)> updated served branch cache in * seconds (glob)
blackbox: add pid to output This adds the process id to the line header for the blackbox output. This is useful for distinguishing processes when using the blackbox on a server and many processes are writing to the blackbox at once.
2015-09-07 21:31:44 +03:00
1970/01/01 00:00:00 bob (*)> wrote served branch cache with 1 labels and 2 nodes (glob)
1970/01/01 00:00:00 bob (*)> 1 incoming changes - new heads: d02f48003e62 (glob)
1970/01/01 00:00:00 bob (*)> pull exited 0 after * seconds (glob)
blackbox: flush output file descriptor Without this, when there are multiple ui views, each blackbox will have its own file handle, and the logging will be in a really bad order. Also, because of the way blackbox works, it never closes its file handles, which means the last output before exit is often lost.
2016-02-03 18:18:29 +03:00
1970/01/01 00:00:00 bob (*)> blackbox -l 6 (glob)
blackbox: tests for the blackbox extension A few tests to cover the blackbox extension. Covers commands, hooks, and incoming changes.
2013-02-10 01:35:30 +04:00
blackbox: prevent failed I/O from causing hg to abort Instead, we simply print a warning message if opening the blackbox log file fails, or if writing to it fails.
2013-03-21 00:40:05 +04:00
we must not cause a failure if we cannot write to the log
$ hg rollback
repository tip rolled back to revision 1 (undo pull)
blackbox: don't run permission tests on non-unix systems The windows and vfat test runs were failing due to read/write permissions not working the same on those systems. On vfat, permissions can't be changed at all, and on windows it seems the chmod emulation doesn't remove read permissions. We could theoretically get the 'cannot write to blacklog.log' test to pass on windows but there's no #if condition to let us exclude vfat only. Verified that test-blackbox passes on windows now.
2013-04-23 05:00:59 +04:00
tests: change blackbox test to work cross platform While it is not easy to make a file 000 on Windows, you can emulate most of the behaviors by replacing the file with a directory. Also corrects test description to properly indicate that failing to read from the log is fatal.
2016-02-03 21:15:18 +03:00
$ mv .hg/blackbox.log .hg/blackbox.log-
$ mkdir .hg/blackbox.log
blackbox: prevent failed I/O from causing hg to abort Instead, we simply print a warning message if opening the blackbox log file fails, or if writing to it fails.
2013-03-21 00:40:05 +04:00
$ hg --debug incoming
tests: change blackbox test to work cross platform While it is not easy to make a file 000 on Windows, you can emulate most of the behaviors by replacing the file with a directory. Also corrects test description to properly indicate that failing to read from the log is fatal.
2016-02-03 21:15:18 +03:00
warning: cannot write to blackbox.log: * (glob)
blackbox: fix a few check-code portability errors
2013-03-27 20:00:43 +04:00
comparing with $TESTTMP/blackboxtest (glob)
blackbox: prevent failed I/O from causing hg to abort Instead, we simply print a warning message if opening the blackbox log file fails, or if writing to it fails.
2013-03-21 00:40:05 +04:00
query 1; heads
searching for changes
all local heads known remotely
changeset: 2:d02f48003e62c24e2659d97d30f2a83abe5d5d51
tag: tip
phase: draft
parent: 1:6563da9dcf87b1949716e38ff3e3dfaa3198eb06
parent: -1:0000000000000000000000000000000000000000
manifest: 2:ab9d46b053ebf45b7996f2922b9893ff4b63d892
user: test
date: Thu Jan 01 00:00:00 1970 +0000
files+: c
extra: branch=default
description:
c
$ hg pull
blackbox: fix a few check-code portability errors
2013-03-27 20:00:43 +04:00
pulling from $TESTTMP/blackboxtest (glob)
blackbox: prevent failed I/O from causing hg to abort Instead, we simply print a warning message if opening the blackbox log file fails, or if writing to it fails.
2013-03-21 00:40:05 +04:00
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
tests: change blackbox test to work cross platform While it is not easy to make a file 000 on Windows, you can emulate most of the behaviors by replacing the file with a directory. Also corrects test description to properly indicate that failing to read from the log is fatal.
2016-02-03 21:15:18 +03:00
a failure reading from the log is fatal
blackbox: prevent failed I/O from causing hg to abort Instead, we simply print a warning message if opening the blackbox log file fails, or if writing to it fails.
2013-03-21 00:40:05 +04:00
$ hg blackbox -l 3
tests: change blackbox test to work cross platform While it is not easy to make a file 000 on Windows, you can emulate most of the behaviors by replacing the file with a directory. Also corrects test description to properly indicate that failing to read from the log is fatal.
2016-02-03 21:15:18 +03:00
abort: *$TESTTMP/blackboxtest2/.hg/blackbox.log* (glob)
blackbox: prevent failed I/O from causing hg to abort Instead, we simply print a warning message if opening the blackbox log file fails, or if writing to it fails.
2013-03-21 00:40:05 +04:00
[255]
tests: change blackbox test to work cross platform While it is not easy to make a file 000 on Windows, you can emulate most of the behaviors by replacing the file with a directory. Also corrects test description to properly indicate that failing to read from the log is fatal.
2016-02-03 21:15:18 +03:00
$ rmdir .hg/blackbox.log
$ mv .hg/blackbox.log- .hg/blackbox.log
blackbox: prevent failed I/O from causing hg to abort Instead, we simply print a warning message if opening the blackbox log file fails, or if writing to it fails.
2013-03-21 00:40:05 +04:00
blackbox: add backup bundle paths to blackbox logs Writes the backup bundle paths to the blackbox so it's easy to see which backup bundle is associated with which command when you are debugging an issue. Example output: 2013/03/13 10:39:56 durham> strip tip 2013/03/13 10:39:59 durham> saved backup bundle to /data/users/durham/www-hg/.hg/strip-backup/e5fac262363a-backup.hg 2013/03/13 10:40:03 durham> strip tip exited 0 after 7.97 seconds
2013-03-13 21:43:51 +04:00
backup bundles get logged
$ touch d
$ hg commit -Amd
adding d
created new head
$ hg strip tip
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
saved backup bundle to $TESTTMP/blackboxtest2/.hg/strip-backup/*-backup.hg (glob)
blackbox: flush output file descriptor Without this, when there are multiple ui views, each blackbox will have its own file handle, and the logging will be in a really bad order. Also, because of the way blackbox works, it never closes its file handles, which means the last output before exit is often lost.
2016-02-03 18:18:29 +03:00
$ hg blackbox -l 6
blackbox: add pid to output This adds the process id to the line header for the blackbox output. This is useful for distinguishing processes when using the blackbox on a server and many processes are writing to the blackbox at once.
2015-09-07 21:31:44 +03:00
1970/01/01 00:00:00 bob (*)> strip tip (glob)
tests: mock getpid to reduce glob usage With util.getpid, it is now possible to define fixed pids. Future iterations can define a map of pids on a locked first come first serve basis to create a more realistic harness, but for now this is good enough. This applies to blackbox, but could apply to other tests as well.
2016-02-03 07:37:04 +03:00
1970/01/01 00:00:00 bob (*)> saved backup bundle to $TESTTMP/blackboxtest2/.hg/strip-backup/73f6ee326b27-7612e004-backup.hg (glob)
tests: change blackbox test to work cross platform While it is not easy to make a file 000 on Windows, you can emulate most of the behaviors by replacing the file with a directory. Also corrects test description to properly indicate that failing to read from the log is fatal.
2016-02-03 21:15:18 +03:00
1970/01/01 00:00:00 bob (*)> updated base branch cache in * seconds (glob)
blackbox: add pid to output This adds the process id to the line header for the blackbox output. This is useful for distinguishing processes when using the blackbox on a server and many processes are writing to the blackbox at once.
2015-09-07 21:31:44 +03:00
1970/01/01 00:00:00 bob (*)> wrote base branch cache with 1 labels and 2 nodes (glob)
1970/01/01 00:00:00 bob (*)> strip tip exited 0 after * seconds (glob)
blackbox: flush output file descriptor Without this, when there are multiple ui views, each blackbox will have its own file handle, and the logging will be in a really bad order. Also, because of the way blackbox works, it never closes its file handles, which means the last output before exit is often lost.
2016-02-03 18:18:29 +03:00
1970/01/01 00:00:00 bob (*)> blackbox -l 6 (glob)
blackbox: add backup bundle paths to blackbox logs Writes the backup bundle paths to the blackbox so it's easy to see which backup bundle is associated with which command when you are debugging an issue. Example output: 2013/03/13 10:39:56 durham> strip tip 2013/03/13 10:39:59 durham> saved backup bundle to /data/users/durham/www-hg/.hg/strip-backup/e5fac262363a-backup.hg 2013/03/13 10:40:03 durham> strip tip exited 0 after 7.97 seconds
2013-03-13 21:43:51 +04:00
blackbox: only show new heads on incoming The blackbox was logging every head after every incoming group. Now we only log the heads that have changed. Added a test. Moved the hooks test to the bottom of the file since the hooks interfer with the tests after it.
2013-02-13 23:07:01 +04:00
extension and python hooks - use the eol extension for a pythonhook
$ echo '[extensions]' >> .hg/hgrc
$ echo 'eol=' >> .hg/hgrc
$ echo '[hooks]' >> .hg/hgrc
$ echo 'update = echo hooked' >> .hg/hgrc
$ hg update
update: wlock the repo for the whole 'hg update' command The update command is touching the repository and should lock it for the length of its operations. Equally importantly, it should lock the repository when it is writing bookmarks. It wasn't doing so until now, leaving doors open for all kinds of drunk beaver parties. This results in some minor tests changes, and the fixing of a couple of bugs from race conditions. Code does not receive any changes beside extra indentation.
2015-08-12 02:26:12 +03:00
hooked
merge: make in-memory changes visible to external update hooks c67339617276 (while 3.4 code-freeze) made all 'update' hooks run after releasing wlock for visibility of in-memory dirstate changes. But this breaks paired invocation of 'preupdate' and 'update' hooks. For example, 'hg backout --merge' for TARGET revision, which isn't parent of CURRENT, consists of steps below: 1. update from CURRENT to TARGET 2. commit BACKOUT revision, which backs TARGET out 3. update from BACKOUT to CURRENT 4. merge TARGET into CURRENT Then, we expects hooks to run in the order below: - 'preupdate' on CURRENT for (1) - 'update' on TARGET for (1) - 'preupdate' on BACKOUT for (3) - 'update' on CURRENT for (3) - 'preupdate' on TARGET for (4) - 'update' on CURRENT/TARGET for (4) But hooks actually run in the order below: - 'preupdate' on CURRENT for (1) - 'preupdate' on BACKOUT for (3) - 'preupdate' on TARGET for (4) - 'update' on TARGET for (1), but actually on CURRENT/TARGET - 'update' on CURRENT for (3), but actually on CURRENT/TARGET - 'update' on CURRENT for (4), but actually on CURRENT/TARGET Root cause of the issue focused by c67339617276 is that external 'update' hook process can't view in-memory changes (especially, of dirstate), because they aren't written out until the end of transaction (or wlock). Now, hooks can be invoked just after updating, because previous patches made in-memory changes visible to external process. This patch may break backward compatibility from the point of view of "scheduling hook execution", but should be reasonable because 'update' hooks had been executed in this order before 3.4. This patch tests "hg backout" and "hg unshelve", because the former activates the transaction before 'update' hook invocation, but the former doesn't.
2015-10-16 19:15:34 +03:00
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
update: warn about other topological heads on bare update A concern around the user experience of Mercurial is user getting stuck on there own topological branch forever. For example, someone pulling another topological branch, missing that message in pull asking them to merge and getting stuck on there own local branch. The current way to "address" this concern was for bare 'hg update' to target the tipmost (also latest pulled) changesets and complain when the update was not linear. That way, failure to merge newly pulled changesets would result in some kind of failure. Yet the failure was quite obscure, not working in all cases (eg: commit right after pull) and the behavior was very impractical in the common case (eg: issue4673). To be able to change that behavior, we need to provide other ways to alert a user stucks on one of many topological head. We do so with an extra message after bare update: 1 other heads for branch "default" Bookmark get its own special version: 1 other divergent bookmarks for "foobar" There is significant room to improve the message itself, and we should augment it with hint about how to see theses other heads or handle the situation (see in-line comment). But having "a" message is already a significant improvement compared to the existing situation. Once we have it we can iterate on a better version of it. As having such message is an important step toward changing the default destination for update and other nicety, I would like to move forward quickly on getting such message. This was discussed during London - October 2015 Sprint.
2016-02-02 17:49:02 +03:00
1 other heads for branch "default"
blackbox: flush output file descriptor Without this, when there are multiple ui views, each blackbox will have its own file handle, and the logging will be in a really bad order. Also, because of the way blackbox works, it never closes its file handles, which means the last output before exit is often lost.
2016-02-03 18:18:29 +03:00
$ hg blackbox -l 6
blackbox: add pid to output This adds the process id to the line header for the blackbox output. This is useful for distinguishing processes when using the blackbox on a server and many processes are writing to the blackbox at once.
2015-09-07 21:31:44 +03:00
1970/01/01 00:00:00 bob (*)> update (glob)
1970/01/01 00:00:00 bob (*)> writing .hg/cache/tags2-visible with 0 tags (glob)
1970/01/01 00:00:00 bob (*)> pythonhook-preupdate: hgext.eol.preupdate finished in * seconds (glob)
1970/01/01 00:00:00 bob (*)> exthook-update: echo hooked finished in * seconds (glob)
1970/01/01 00:00:00 bob (*)> update exited 0 after * seconds (glob)
blackbox: flush output file descriptor Without this, when there are multiple ui views, each blackbox will have its own file handle, and the logging will be in a really bad order. Also, because of the way blackbox works, it never closes its file handles, which means the last output before exit is often lost.
2016-02-03 18:18:29 +03:00
1970/01/01 00:00:00 bob (*)> blackbox -l 6 (glob)
blackbox: only show new heads on incoming The blackbox was logging every head after every incoming group. Now we only log the heads that have changed. Added a test. Moved the hooks test to the bottom of the file since the hooks interfer with the tests after it.
2013-02-13 23:07:01 +04:00
blackbox: automatically rotate log files If enabled, log rotation prevents the amount of space used by the blackbox log from growing without bound. This becomes important in cases where there are a lot of busy repositories managed by humans and automation on many machines. In large deployments, we cannot reasonably track all the repos where blackbox logs need to be managed, so it is safer to have blackbox manage its own logs than to move responsibility to an external tool such as logrotate. This change adds two configuration keys: * blackbox.maxsize is the maximum allowable size of the current log * blackbox.maxfiles is the number of log files to maintain
2013-04-19 03:17:59 +04:00
log rotation
$ echo '[blackbox]' >> .hg/hgrc
$ echo 'maxsize = 20 b' >> .hg/hgrc
$ echo 'maxfiles = 3' >> .hg/hgrc
$ hg status
$ hg status
$ hg status
$ hg tip -q
tests: move blackbox testing of tags to test-tags.t We're going to refactor tags cache shortly. It is easier to test the blackbox logging if these tests are in test-tags.t.
2015-04-13 20:28:37 +03:00
2:d02f48003e62
blackbox: automatically rotate log files If enabled, log rotation prevents the amount of space used by the blackbox log from growing without bound. This becomes important in cases where there are a lot of busy repositories managed by humans and automation on many machines. In large deployments, we cannot reasonably track all the repos where blackbox logs need to be managed, so it is safer to have blackbox manage its own logs than to move responsibility to an external tool such as logrotate. This change adds two configuration keys: * blackbox.maxsize is the maximum allowable size of the current log * blackbox.maxfiles is the number of log files to maintain
2013-04-19 03:17:59 +04:00
$ ls .hg/blackbox.log*
.hg/blackbox.log
.hg/blackbox.log.1
.hg/blackbox.log.2
tests: change blackbox test to work cross platform While it is not easy to make a file 000 on Windows, you can emulate most of the behaviors by replacing the file with a directory. Also corrects test description to properly indicate that failing to read from the log is fatal.
2016-02-03 21:15:18 +03:00
$ cd ..
$ hg init blackboxtest3
$ cd blackboxtest3
$ hg blackbox
blackbox: flush output file descriptor Without this, when there are multiple ui views, each blackbox will have its own file handle, and the logging will be in a really bad order. Also, because of the way blackbox works, it never closes its file handles, which means the last output before exit is often lost.
2016-02-03 18:18:29 +03:00
1970/01/01 00:00:00 bob (*)> blackbox (glob)
tests: change blackbox test to work cross platform While it is not easy to make a file 000 on Windows, you can emulate most of the behaviors by replacing the file with a directory. Also corrects test description to properly indicate that failing to read from the log is fatal.
2016-02-03 21:15:18 +03:00
$ mv .hg/blackbox.log .hg/blackbox.log-
$ mkdir .hg/blackbox.log
$ sed -e 's/\(.*test1.*\)/#\1/; s#\(.*commit2.*\)#os.rmdir(".hg/blackbox.log")\nos.rename(".hg/blackbox.log-", ".hg/blackbox.log")\n\1#' $TESTDIR/test-dispatch.py > ../test-dispatch.py
$ python ../test-dispatch.py
running: add foo
result: 0
running: commit -m commit1 -d 2000-01-01 foo
result: None
running: commit -m commit2 -d 2000-01-02 foo
result: None
running: log -r 0
changeset: 0:0e4634943879
user: test
date: Sat Jan 01 00:00:00 2000 +0000
summary: commit1
result: None
running: log -r tip
changeset: 1:45589e459b2e
tag: tip
user: test
date: Sun Jan 02 00:00:00 2000 +0000
summary: commit2
result: None
$ hg blackbox
1970/01/01 00:00:00 bob (*)> blackbox (glob)
1970/01/01 00:00:00 bob (*)> blackbox exited 0 after * seconds (glob)
blackbox: flush output file descriptor Without this, when there are multiple ui views, each blackbox will have its own file handle, and the logging will be in a really bad order. Also, because of the way blackbox works, it never closes its file handles, which means the last output before exit is often lost.
2016-02-03 18:18:29 +03:00
1970/01/01 00:00:00 bob (*)> blackbox (glob)
blackbox: automatically rotate log files If enabled, log rotation prevents the amount of space used by the blackbox log from growing without bound. This becomes important in cases where there are a lot of busy repositories managed by humans and automation on many machines. In large deployments, we cannot reasonably track all the repos where blackbox logs need to be managed, so it is safer to have blackbox manage its own logs than to move responsibility to an external tool such as logrotate. This change adds two configuration keys: * blackbox.maxsize is the maximum allowable size of the current log * blackbox.maxfiles is the number of log files to maintain
2013-04-19 03:17:59 +04:00
blackbox: tests for the blackbox extension A few tests to cover the blackbox extension. Covers commands, hooks, and incoming changes.
2013-02-10 01:35:30 +04:00
cleanup
$ cd ..
Reference in New Issue Copy Permalink