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'.
Issue1678: IndexError when pushing
setting up base repo
$ hg init a
$ cd a
$ touch a
$ hg ci -Am a
adding a
$ cd ..
cloning base repo
$ hg clone a b
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd b
setting up cset to push
$ hg up null
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ touch a
different msg so we get a clog new entry
$ hg ci -Am b
adding a
created new head
pushing
$ hg push -f ../a
pushing to ../a
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 0 changes to 0 files (+1 heads)
$ cd ..