Fri, 09 Oct 2015 15:31:50 -0700 shelve: rename 'publicancestors' to something accurate (issue4737)
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 09 Oct 2015 15:31:50 -0700] rev 26602
shelve: rename 'publicancestors' to something accurate (issue4737) That function is actually not returning public ancestors at all. This is pointed by the second line of the docstring... The bundling behavior was made correct in a5141977198d but with confusion remaining regarding what each function was doing. This close issue4737, because this highlight that shelve is actually -not- bundling too much data (this was actually properly tested).
Fri, 09 Oct 2015 12:30:46 -0500 makefile: add wheel build target
Nathan Goldbaum <ngoldbau@ucsc.edu> [Fri, 09 Oct 2015 12:30:46 -0500] rev 26601
makefile: add wheel build target
Fri, 09 Oct 2015 12:25:51 -0500 setup: import setup from setuptools if FORCE_SETUPTOOLS is set
Nathan Goldbaum <ngoldbau@ucsc.edu> [Fri, 09 Oct 2015 12:25:51 -0500] rev 26600
setup: import setup from setuptools if FORCE_SETUPTOOLS is set This should allow easier experimentation with using setuptools in mercurial's build automation, without breaking anything that currently depends on distutils behavior
Mon, 12 Oct 2015 14:46:51 +0100 hgweb: remove obsolete -webkit-border-radius property
Gijs Kruitbosch <gijskruitbosch@gmail.com> [Mon, 12 Oct 2015 14:46:51 +0100] rev 26599
hgweb: remove obsolete -webkit-border-radius property
Mon, 12 Oct 2015 15:20:04 +0800 monoblue: add a link to the latest file revision
Anton Shestakov <av6@dwimlabs.net> [Mon, 12 Oct 2015 15:20:04 +0800] rev 26598
monoblue: add a link to the latest file revision For reference, this was added to paper/coal in bb00a159e594 and to gitweb in b3b57ecbda50.
Fri, 09 Oct 2015 15:44:00 -0700 discovery: reference relevant bug in the faulty code
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 09 Oct 2015 15:44:00 -0700] rev 26597
discovery: reference relevant bug in the faulty code We extend the comment about this code flaw with more code flaw.
Fri, 09 Oct 2015 15:37:05 -0700 discovery: fix a typo in a comment
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 09 Oct 2015 15:37:05 -0700] rev 26596
discovery: fix a typo in a comment The idea here is that the code is imperfect, not that it is impossible to get something behaving properly.
Fri, 09 Oct 2015 14:59:37 -0700 getsubset: get the unpacker version from the bundler
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 09 Oct 2015 14:59:37 -0700] rev 26595
getsubset: get the unpacker version from the bundler The current setup requires to pass both a packer and, optionally, the version of the unpacker. This is confusing and error prone as the two value cannot mismatch. Instead, we simply grab the version from the packer. This fixes a bug where requesting a cg2 from 'hg bundle' were reported as changegroup 1. I should have caught that in the initial changeset but I missed it somehow.
Mon, 12 Oct 2015 15:42:32 +0300 test-convert-cvs: add sleep so cvs notices changes
Emanuele Giaquinta <emanuele.giaquinta@gmail.com> [Mon, 12 Oct 2015 15:42:32 +0300] rev 26594
test-convert-cvs: add sleep so cvs notices changes This change makes the test pass on gcc112.fsffrance.org.
Wed, 07 Oct 2015 11:33:52 +0300 cvsps: fix computation of parent revisions when log caching is on
Emanuele Giaquinta <emanuele.giaquinta@gmail.com> [Wed, 07 Oct 2015 11:33:52 +0300] rev 26593
cvsps: fix computation of parent revisions when log caching is on cvsps computes the parent revisions of log entries by walking the cvs log sorted by (rcs, revision) and by iteratively maintaining a 'versions' dictionary which maps a (rcs, branch) pair onto the last revision seen for that pair. When log caching is on and a log cache exists, cvsps fails to set the parent revisions of new log entries because it does not iterate over the log cache in the parents computation. A complication is that a file rcs can change (move to/from the attic), with respect to its value in the log cache, if the file is removed/added back. This patch adds an iteration over the log cache to update the rcs of cached log entries, if changed, and to properly populate the 'versions' dictionary.
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.
Mon, 05 Oct 2015 16:34:17 -0700 histedit: add inprogress method to state class
Christian Delahousse <cdelahousse@fb.com> [Mon, 05 Oct 2015 16:34:17 -0700] rev 26582
histedit: add inprogress method to state class If a histedit is progress, the 'histedit-state' file should exist. The patch implements a convenience function to do check if a histedit is in progress. This method will be use in next patch in the series.
Fri, 09 Oct 2015 03:53:47 +0900 commands: use dirstateguard instead of begin/end-parentchange for backout
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Oct 2015 03:53:47 +0900] rev 26581
commands: use dirstateguard instead of begin/end-parentchange for backout Before this patch, "hg backout" uses 'begin'/'end'-'parentchange()' of 'dirstate' class to avoid writing incomplete dirstate changes out at failure. But this framework doesn't work as expected, if 'dirstate.write()' is invoked between them. In fact, in-memory dirstate changes may be written out at 'repo.status()' implied by 'merge.update()', even before this patch. To restore dirstate as expected at failure of "hg backout", this patch uses 'dirstateguard' instead of 'begin'/'end'-'parentchange()'.
Fri, 09 Oct 2015 03:53:47 +0900 commands: make "hg import" use dirstateguard only for --no-commit
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Oct 2015 03:53:47 +0900] rev 26580
commands: make "hg import" use dirstateguard only for --no-commit Previous patch made dirstate changes in a transaction scope "all or nothing". Therefore, 'dirstateguard' is meaningless, if its scope is as same as one of the related transaction. Before this patch, "hg import" uses 'dirstateguard' always, but transaction is also started if '--no-commit' isn't specified. To avoid redundancy, this patch makes "hg import" use dirstateguard only if transaction isn't started (= '--no-commit' is specified). In this patch, 'if dsguard' can be examined safely, because 'dsguard' is initialized (with None) before outermost 'try'.
Fri, 09 Oct 2015 03:53:46 +0900 cmdutil: stop tryimportone from using dirstateguard (BC)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Oct 2015 03:53:46 +0900] rev 26579
cmdutil: stop tryimportone from using dirstateguard (BC) There is no user of 'cmdutil.tryimportone()' other than 'commands.import_()', which can restore dirstate at failure of applying patches by transaction or dirstateguard. Therefore, it is reasonable to stop 'tryimportone()' from using redundant 'dirstateguard', even though it changes behavior of 'tryimportone()'. After this patch, 3rd party extensions should use 'dirstateguard' or so explicitly, if they want to restore dirstate at failure of importing a patch.
Fri, 09 Oct 2015 03:53:46 +0900 dirstate: remove meaningless dirstateguard
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Oct 2015 03:53:46 +0900] rev 26578
dirstate: remove meaningless dirstateguard Previous patch made dirstate changes in a transaction scope "all or nothing". Therefore, 'dirstateguard' is meaningless, if its scope is as same as one of the related transaction. This patch removes such meaningless 'dirstateguard' usage.
Fri, 09 Oct 2015 03:53:46 +0900 localrepo: execute appropriate actions for dirstate at releasing transaction
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Oct 2015 03:53:46 +0900] rev 26577
localrepo: execute appropriate actions for dirstate at releasing transaction Before this patch, in-memory dirstate changes are still kept over a transaction scope boundary regardless of the result of it. For "all or nothing" policy of the transaction, in-memory dirstate changes should be: - written out at successful closing a transaction, because subsequent 'dirstate.invalidate()' can lose them - discarded at failure of a transaction, because outer 'wlock.release()' or so may write them out To discard all changes in a transaction completely, this patch also restores '.hg/dirstate' by '.hg/journal.dirstate' at failure, because 'transaction' itself does nothing for files related to '.hg/journal.*' in such case (therefore, renaming in this patch is safe enough). This is a part of preparations for "transactional dirstate". See also the wiki page below for detail about it. https://mercurial.selenic.com/wiki/DirstateTransactionPlan This patch also removes redundant 'dirstate.invalidate()' just before aborting a transaction for shelve/unshelve.
Fri, 09 Oct 2015 03:53:46 +0900 transaction: add releasefn to notify the end of a transaction scope
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Oct 2015 03:53:46 +0900] rev 26576
transaction: add releasefn to notify the end of a transaction scope 'releasefn' is used by subsequent patch, to do appropriate action according to the result of it at the end of a transaction scope. To ensure that 'releasefn' is invoked only once, this patch invokes it after assignment 'self.journal = None', because such assignment prevents from invoked 'transaction._abort()' again via '__del__()'. def __del__(self): if self.journal: self._abort()
Wed, 07 Oct 2015 23:35:30 -0700 filemerge: move post-merge checks into a separate function
Siddharth Agarwal <sid0@fb.com> [Wed, 07 Oct 2015 23:35:30 -0700] rev 26575
filemerge: move post-merge checks into a separate function This makes the overall filemerge function easier to follow, and makes upcoming work simpler.
Thu, 08 Oct 2015 14:18:43 -0700 filemerge._xmerge: drop no longer necessary 'if r:' check
Siddharth Agarwal <sid0@fb.com> [Thu, 08 Oct 2015 14:18:43 -0700] rev 26574
filemerge._xmerge: drop no longer necessary 'if r:' check Cleanup from an earlier patch to make premerge be directly called from the main filemerge function.
Thu, 08 Oct 2015 14:17:31 -0700 filemerge._idump: drop no longer necessary 'if r:' check
Siddharth Agarwal <sid0@fb.com> [Thu, 08 Oct 2015 14:17:31 -0700] rev 26573
filemerge._idump: drop no longer necessary 'if r:' check Cleanup from an earlier patch to make premerge be directly called from the main filemerge function.
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip