Wed, 05 Nov 2014 09:27:08 +0000 transaction: allow registering a temporary transaction file
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.
Thu, 13 Nov 2014 10:22:47 +0000 transaction: always generate file on close
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.
Sun, 09 Nov 2014 12:31:34 -0500 remove: move most of the implementation into cmdutils.remove()
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.
Tue, 11 Nov 2014 20:08:19 -0800 revlog: increase I/O bound to 4x the amount of data consumed
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.
Tue, 11 Nov 2014 20:01:19 -0800 revlog: bound based on the length of the compressed deltas
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.
Tue, 11 Nov 2014 19:54:36 -0800 revlog: compute length of compressed deltas along with chain length
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.
Tue, 11 Nov 2014 21:41:12 -0800 revlog: store fulltext when compressed delta is bigger than it
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.
Tue, 11 Nov 2014 21:39:56 -0800 revlog: make a predicate clearer with parens
Siddharth Agarwal <sid0@fb.com> [Tue, 11 Nov 2014 21:39:56 -0800] rev 23284
revlog: make a predicate clearer with parens
Wed, 05 Nov 2014 13:06:24 +0000 transaction: extract backupentry registration in a dedicated function
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.
Sat, 08 Nov 2014 16:35:15 +0000 transaction: pass the transaction to 'postclose' callback
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.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip