Sat, 16 Nov 2013 15:46:29 -0500 bisect: --command without --noupdate should flag the parent rev it tested
Mads Kiilerich <madski@unity3d.com> [Sat, 16 Nov 2013 15:46:29 -0500] rev 20237
bisect: --command without --noupdate should flag the parent rev it tested 14913fcb30c6 not only introduced the 'bisect(current)' revset predicate, it also changed how the 'current' revision is used in combination with --command. The new behaviour might be ok for --noupdate where the working directory and its revision shouldn't be used, but it also did that when --command is used to run a command on the currently checked out revision then it could register the test result on the wrong revision. An example: Before, bisect with --command could use the wrong revision when recording the test result: $ hg up -qr 0 $ hg bisect --command "python \"$TESTTMP/script.py\" and some parameters" changeset 31:58c80a7c8a40: bad abort: inconsistent state, 31:58c80a7c8a40 is good and bad Now it works as before and as expected and uses the working directory revision for the --command result: $ hg up -qr 0 $ hg bisect --command "python \"$TESTTMP/script.py\" and some parameters" changeset 0:b99c7b9c8e11: bad ...
Sat, 16 Nov 2013 15:46:29 -0500 context: drop caching 'copies' method
Mads Kiilerich <madski@unity3d.com> [Sat, 16 Nov 2013 15:46:29 -0500] rev 20236
context: drop caching 'copies' method The 'copies' method has no test coverage and calls copies.pathcopies with an incorrect number of parameters and is thus (fortunately) not used. Kill it.
Tue, 19 Nov 2013 12:43:29 -0800 commands.bookmarks: move hexfn to inside list block
Siddharth Agarwal <sid0@fb.com> [Tue, 19 Nov 2013 12:43:29 -0800] rev 20235
commands.bookmarks: move hexfn to inside list block This isn't used outside this block, nor is it expected to be.
Tue, 19 Nov 2013 12:42:17 -0800 commands.bookmarks: move cur initialization to inside wlock
Siddharth Agarwal <sid0@fb.com> [Tue, 19 Nov 2013 12:42:17 -0800] rev 20234
commands.bookmarks: move cur initialization to inside wlock This is more correct because we now fetch '.' while nothing else can interfere with it.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip