Thomas Arendsen Hein <thomas@intevation.de> [Thu, 06 Nov 2014 09:36:39 +0100] rev 23206
convert: use git diff-tree -Cn% instead of --find-copies=n% for older git
The option --find-copies was added in a later git version than the one included
in Debian squeeze-lts (1.7.2.5), probably around 1.7.4.
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.
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.
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.
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.
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'.
Matt Mackall <mpm@selenic.com> [Wed, 05 Nov 2014 12:41:12 -0600] rev 23200
merge with stable