Fri, 17 Oct 2014 21:55:31 -0700 changelog: handle writepending in the transaction
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 17 Oct 2014 21:55:31 -0700] rev 23203
changelog: handle writepending in the transaction The 'delayupdate' method now takes a transaction object and registers its '_writepending' method for execution in 'transaction.writepending()'. The hook can then use 'transaction.writepending()' directly. At some point this will allow the addition of other file creation during writepending.
Fri, 17 Oct 2014 21:19:54 -0700 transaction: add 'writepending' logic
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 17 Oct 2014 21:19:54 -0700] rev 23202
transaction: add 'writepending' logic The contents of the transaction must be flushed to disk before running a hook. But it must be flushed to a special file so that the normal reader does not use it. This logic is currently in the changelog only. We add some facility to register such operations in the transaction itself.
Sat, 18 Oct 2014 01:12:18 -0700 changelog: rework the delayupdate mechanism
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 18 Oct 2014 01:12:18 -0700] rev 23201
changelog: rework the delayupdate mechanism The current way we use the 'delayupdate' mechanism is wrong. We call 'delayupdate' right after the transaction retrieval, then we call 'finalize' right before calling 'tr.close()'. The 'finalize' call will -always- result in a flush to disk, making the data available to all readers. But the 'tr.close()' may be a no-op if the transaction is nested. This would result in data: 1) exposed to reader too early, 2) rolled back by other part of the transaction after such exposure So we need to end up in a situation where we call 'finalize' a single time when the transaction actually closes. For this purpose we need to be able to call 'delayupdate' and '_writepending' multiple times and 'finalize' once. This was not possible with the previous state of the code. This changeset refactors the code to makes this possible. We buffer data in memory as much as possible and fall-back to writing to a ".a" file after the first call to '_writepending'.
Wed, 05 Nov 2014 12:41:12 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Wed, 05 Nov 2014 12:41:12 -0600] rev 23200
merge with stable
Wed, 05 Nov 2014 17:25:00 +0000 bookmarks: fix formatting of exchange message (issue4439) stable
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 05 Nov 2014 17:25:00 +0000] rev 23199
bookmarks: fix formatting of exchange message (issue4439) The message formatting was crashing when doing explicit pulling `hg pull -B X`. This changeset fix it and improved the test coverage.
Tue, 04 Nov 2014 12:26:06 -0800 test-status-rev: document one more broken test
Martin von Zweigbergk <martinvonz@google.com> [Tue, 04 Nov 2014 12:26:06 -0800] rev 23198
test-status-rev: document one more broken test The status for missing_content2_content2-untracked doesn't get reported at all. Since the file does exist in the working copy, it should reported as unknown. Document that in the test.
Tue, 04 Nov 2014 16:09:52 -0800 test-status-rev: use common script for generating file history
Martin von Zweigbergk <martinvonz@google.com> [Tue, 04 Nov 2014 16:09:52 -0800] rev 23197
test-status-rev: use common script for generating file history Start using the generate-working-copy-states.py script that's shared with test-revert.t, instead of creating the states manually in the test. This adds several states that are currently missing. We will start checking those states later.
Mon, 20 Oct 2014 23:56:55 -0700 test-status-rev: use same names as from generate-working-copy-states
Martin von Zweigbergk <martinvonz@google.com> [Mon, 20 Oct 2014 23:56:55 -0700] rev 23196
test-status-rev: use same names as from generate-working-copy-states To prepare for using generate-working-copy-states.py for generating the files and their content, let's start by renaming the files according to the naming scheme used by that script.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip