Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 05 Nov 2014 09:27:08 +0000] rev 23291
transaction: allow registering a temporary transaction file
During the transaction, files may be created to store or expose data
involved in the transaction (eg: changelog index data are written in
a 'changelog.i.a' for hooks). But we do not have an official way to
record such file creation and make sure they are cleaned up. The lack
of clean-up is currently okay because there is a single file involved
and a single producer/consumer.
However, as we want to expose more data (bookmarks, phases, obsmarker)
we need something more solid. The 'backupentries' mechanism could
handle that. Temporary files can be encoded as a backup of nothing
'('', <temporarypath>)'. We "need" to attach it to the same mechanism
as we use to be able to use temporary transaction files outside of
.'store/' and 'backupentries' is expected to gain such feature.
This changeset makes it clear that we should rename 'backupentries' to
something more generic.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 13 Nov 2014 10:22:47 +0000] rev 23290
transaction: always generate file on close
The conditionnal was buggy and file were only generated if "onclose" was
defined. By luck, "onclose" was always defined.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 09 Nov 2014 12:31:34 -0500] rev 23289
remove: move most of the implementation into cmdutils.remove()
This will allow access to the reusable parts from subrepos, similar to add(),
forget(), etc.
Siddharth Agarwal <sid0@fb.com> [Tue, 11 Nov 2014 20:08:19 -0800] rev 23288
revlog: increase I/O bound to 4x the amount of data consumed
This doesn't affect normal clones since they'd be bound by the CPU bound below
anyway -- it does, however, improve generaldelta clones significantly.
This also results in better deltaing for generaldelta clones -- in generaldelta
clones, we calculate deltas with respect to the closest base if it has a higher
revision number than either parent. If the base is on a significantly different
branch, this can result in pointlessly massive deltas. This reduces the number
of bases and hence the number of bad deltas.
Empirically, for a highly branchy repository, this resulted in an improvement
of around 15% to manifest size.
Siddharth Agarwal <sid0@fb.com> [Tue, 11 Nov 2014 20:01:19 -0800] rev 23287
revlog: bound based on the length of the compressed deltas
This is only relevant for generaldelta clones.
Siddharth Agarwal <sid0@fb.com> [Tue, 11 Nov 2014 19:54:36 -0800] rev 23286
revlog: compute length of compressed deltas along with chain length
In upcoming patches to the revlog, we're going to split up the notions of
bounding I/O and bounding CPU.
Siddharth Agarwal <sid0@fb.com> [Tue, 11 Nov 2014 21:41:12 -0800] rev 23285
revlog: store fulltext when compressed delta is bigger than it
This is a very silly case and not particularly likely to happen in the wild,
but it turns out we can hit it in a couple of places. As we tune the storage
parameters we're likely to hit more such cases.
The affected test cases all have smaller revlogs now.
Siddharth Agarwal <sid0@fb.com> [Tue, 11 Nov 2014 21:39:56 -0800] rev 23284
revlog: make a predicate clearer with parens
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 05 Nov 2014 13:06:24 +0000] rev 23283
transaction: extract backupentry registration in a dedicated function
We are about to use the 'backupentry' mechanism to allow cleaning up
transaction-related temporary files (such as 'changelog.i.a'). We start
by extracting the entry registration into its own method for easy reuse.
At that point, I would like to rename the backup-file related variable to
something generic but I'm a bit short of ideas.
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 08 Nov 2014 16:35:15 +0000] rev 23282
transaction: pass the transaction to 'postclose' callback
This mirrors the API for 'pending' and 'finalize' callbacks. I do not have
immediate usage planned for it, but I'm sure some callback will be happy to
access transaction related data.