Tue, 06 Oct 2015 16:26:20 -0500 dirstate: batch calls to statfiles (issue4878)
Matt Mackall <mpm@selenic.com> [Tue, 06 Oct 2015 16:26:20 -0500] rev 26592
dirstate: batch calls to statfiles (issue4878) This makes it more interruptible.
Sun, 11 Oct 2015 18:30:47 +0900 parsers: fix infinite loop or out-of-bound read in fm1readmarkers (issue4888)
Yuya Nishihara <yuya@tcha.org> [Sun, 11 Oct 2015 18:30:47 +0900] rev 26591
parsers: fix infinite loop or out-of-bound read in fm1readmarkers (issue4888) The issue4888 was caused by 0-length obsolete marker. If msize is zero, fm1readmarkers() never ends. This patch adds several bound checks to fm1readmarker(). Therefore, 0-length and invalid-size marker should be rejected.
Sun, 11 Oct 2015 18:41:41 +0900 parsers: read sizes of metadata pair of obsolete marker at once
Yuya Nishihara <yuya@tcha.org> [Sun, 11 Oct 2015 18:41:41 +0900] rev 26590
parsers: read sizes of metadata pair of obsolete marker at once This will make it easy to implement bound checking. Currently fm1readmarker() has no protection for corrupted obsstore and can cause infinite loop or out-of-bound reads.
Wed, 07 Oct 2015 21:51:24 -0700 filemerge: clean up temp files in a finally block
Siddharth Agarwal <sid0@fb.com> [Wed, 07 Oct 2015 21:51:24 -0700] rev 26589
filemerge: clean up temp files in a finally block This isn't really a big deal because the temp files are created in $TMPDIR, but it makes some upcoming work simpler.
Thu, 08 Oct 2015 12:53:09 -0700 check-code: detect and ban 'util.Abort'
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 08 Oct 2015 12:53:09 -0700] rev 26588
check-code: detect and ban 'util.Abort' We have seen the light, please use the new way.
Thu, 08 Oct 2015 12:55:45 -0700 error: get Abort from 'error' instead of 'util'
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 08 Oct 2015 12:55:45 -0700] rev 26587
error: get Abort from 'error' instead of 'util' The home of 'Abort' is 'error' not 'util' however, a lot of code seems to be confused about that and gives all the credit to 'util' instead of the hardworking 'error'. In a spirit of equity, we break the cycle of injustice and give back to 'error' the respect it deserves. And screw that 'util' poser. For great justice.
Mon, 05 Oct 2015 22:49:24 -0700 eol: rename 'error' to 'haserror'
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 22:49:24 -0700] rev 26586
eol: rename 'error' to 'haserror' The variable 'error' conflict with the module name that we would like to import and use in a coming changeset.
Mon, 05 Oct 2015 22:29:57 -0700 discovery: rename 'error' to 'errormsg'
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 22:29:57 -0700] rev 26585
discovery: rename 'error' to 'errormsg' The variable 'error' conflict with the module name that we would like to import and use in a coming changeset.
Mon, 05 Oct 2015 16:44:45 -0700 histedit: delete histedit statefile on any exception during abort
Christian Delahousse <cdelahousse@fb.com> [Mon, 05 Oct 2015 16:44:45 -0700] rev 26584
histedit: delete histedit statefile on any exception during abort When an user aborts a histedit, many things could go wrong. At a minimum, after a histedit abort failure, their repository should be out of that state. We've found situations where the user could not exit the histedit state without manually deleting the histedit state file. This patch ensures that if any exception happens during an abort, the histedit statefile will be deleted so that users are out of the histedit state and can at least manually get the repo back to a workable condition.
Tue, 06 Oct 2015 15:09:28 -0700 histedit: check presence of statefile before deleting it
Christian Delahousse <cdelahousse@fb.com> [Tue, 06 Oct 2015 15:09:28 -0700] rev 26583
histedit: check presence of statefile before deleting it When the histeditstate class instance has it's clear() method called, there is nothing to check to see if the state file exists before deleting it. It may not exist, which would create an exception. This patch allows clear to be called at any time. This will be needed for the following patch.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip