Siddharth Agarwal <sid0@fb.com> [Wed, 12 Nov 2014 23:19:44 -0800] rev 23293
mdiff.diffopts: add doc comment for nobinary
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 08 Nov 2014 17:08:09 +0000] rev 23292
changelog: register changelog.i.a as a temporary file
The file is registered to make sure the transaction is cleaned up in all cases.
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.