Sat, 18 Oct 2014 01:09:41 -0700 changelog: rely on transaction for finalization
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 18 Oct 2014 01:09:41 -0700] rev 23205
changelog: rely on transaction for finalization Instead of calling 'cl.finalize()' by hand (possibly at a bogus time) we register it in the transaction during 'delayupdate' and rely on 'tr.close()' to call it at the right time.
Fri, 17 Oct 2014 22:28:09 -0700 transaction: allow registering a finalization callback
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 17 Oct 2014 22:28:09 -0700] rev 23204
transaction: allow registering a finalization callback The new 'addfinalize' method allows people to register a callback to be triggered when the transaction is closed. This aims to get rid of explicit calls to 'changelog.finalize'. This also obsoletes the 'onclose' function but removing it is not in the scope of this series.
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.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip