Thu, 15 Oct 2015 12:45:34 +0100 obsstore: make the readonly attribute accessible
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 15 Oct 2015 12:45:34 +0100] rev 26684
obsstore: make the readonly attribute accessible We want to gracefully handle the read only case in some case (current target: advisory obsmarkers parts in bundle2). So we expose the attribute in a clean way.
Mon, 05 Oct 2015 04:26:26 -0700 update: introduce a 'UpdateAbort' exception
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 04:26:26 -0700] rev 26683
update: introduce a 'UpdateAbort' exception The 'postincoming' function used by 'hg pull --update' and 'hg unbundle' is catching 'Abort' exceptions to intercept failed update. This feel a bit too wide to me, so I'm introducing a more precise exception to specify update destination issues.
Mon, 05 Oct 2015 21:42:09 -0700 update: "deprecate" call to 'merge.update' without a destination
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 21:42:09 -0700] rev 26682
update: "deprecate" call to 'merge.update' without a destination Now that all internal callers pre-compute and set a destination at a higher level it feels like we can kill this API. This will allow us to simplify this function. However I feel like this is a bit too central and critical to break now. I'm adding a devel warning to let extension make catch this in the next cycle.
Wed, 14 Oct 2015 20:35:06 -0700 shelve: delete shelve statefile on any exception during abort
Christian Delahousse <cdelahousse@fb.com> [Wed, 14 Oct 2015 20:35:06 -0700] rev 26681
shelve: delete shelve statefile on any exception during abort When a user's repository is in an unfinished unshelve state and they choose to abort, at a minimum, the repo should be out of that state. We've found situations where the user could not leave the state unless manually deleting the state file. This fix ensures that no matter what exception may be raised during the abort, the shelved state file will be deleted, the user will be out of the unshelve state and they can get their repository into a workable condition.
Wed, 14 Oct 2015 18:22:16 -0700 highlight: add option to prevent content-only based fallback
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 14 Oct 2015 18:22:16 -0700] rev 26680
highlight: add option to prevent content-only based fallback When Mozilla enabled Pygments on hg.mozilla.org, we got a lot of weirdly colorized files. Upon further investigation, the hightlight extension is first attempting a filename+content based match then falling back to a purely content-driven detection mode in Pygments. Sounds good in theory. Unfortunately, Pygments' content-driven detection establishes no minimum threshold for returning a lexer. Furthermore, the detection code for a number of languages is very liberal. For example, ActionScript 3 will return a confidence of 0.3 (out of 1.0) if the first 1k of the file we pass in matches the regex "\w+\s*:\s*\w"! Python matches on "import ". It's no coincidence that a number of our extension-less files were getting highlighted improperly. This patch adds an option to have the highlighter not fall back to purely content-based detection when filename+content detection failed. This can be enabled to render unlighted text instead of taking the risk that unknown file types are highlighted incorrectly. The old behavior is still the default.
Wed, 14 Oct 2015 17:43:44 -0700 highlight: inline checkfctx()
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 14 Oct 2015 17:43:44 -0700] rev 26679
highlight: inline checkfctx() It is only used once. pygmentize() is pretty small. Let's just inline it.
Wed, 14 Oct 2015 17:42:07 -0700 highlight: consolidate duplicate code
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 14 Oct 2015 17:42:07 -0700] rev 26678
highlight: consolidate duplicate code I'm adding some logic in a future patch and this will make it so I only have to add it once.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip