Wed, 15 Oct 2014 08:38:16 -0700 histedit: read state from histeditstate
David Soria Parra <davidsp@fb.com> [Wed, 15 Oct 2014 08:38:16 -0700] rev 22983
histedit: read state from histeditstate Read the state in histeditstate. This allows us to correctly update internal variables when necessary without having to recreate a new state. When we read a state in _histedit state while we will already have state passed from histedit(), we can read the state in place and don't have to merge two histeditstates.
Wed, 15 Oct 2014 08:18:26 -0700 histedit: pass state to action functions
David Soria Parra <davidsp@fb.com> [Wed, 15 Oct 2014 08:18:26 -0700] rev 22982
histedit: pass state to action functions
Thu, 16 Oct 2014 10:06:49 -0700 histedit: pass state to processreplacement
David Soria Parra <davidsp@fb.com> [Thu, 16 Oct 2014 10:06:49 -0700] rev 22981
histedit: pass state to processreplacement
Wed, 15 Oct 2014 08:06:15 -0700 histedit: pass state to boostrapcontinue
David Soria Parra <davidsp@fb.com> [Wed, 15 Oct 2014 08:06:15 -0700] rev 22980
histedit: pass state to boostrapcontinue Pass the state to boostrapcontinue and remove the unecessary passing of repo.
Wed, 15 Oct 2014 17:11:54 -0700 histedit: let the state expose a context but serialize correctly to nodes
David Soria Parra <davidsp@fb.com> [Wed, 15 Oct 2014 17:11:54 -0700] rev 22979
histedit: let the state expose a context but serialize correctly to nodes The histedit code often expects a context. However histedit hands around the tuple for the serialization and therefore hand over a parentctxnode. This leads to code having to return a context based on the parentctxnode. We let the state only return a context but correctly serialize and deserialze to a node.
Wed, 15 Oct 2014 17:30:57 -0700 histedit: add clear method to remove state
David Soria Parra <davidsp@fb.com> [Wed, 15 Oct 2014 17:30:57 -0700] rev 22978
histedit: add clear method to remove state Encapsulate the unlinking histedit-state and use the vfs layer instead of os.unlink.
Tue, 14 Oct 2014 20:35:17 -0700 histedit: use state object where necessary
David Soria Parra <davidsp@fb.com> [Tue, 14 Oct 2014 20:35:17 -0700] rev 22977
histedit: use state object where necessary We are using the properties from the state object where necessary and ensure that the state is set correctly.
Wed, 15 Oct 2014 17:17:12 -0700 histedit: add histedit state class
David Soria Parra <davidsp@fb.com> [Wed, 15 Oct 2014 17:17:12 -0700] rev 22976
histedit: add histedit state class Add an histeditstate class that is intended to hold the current state. This allows us encapsulate the state and avoids passing around a tuple which is based on the serialization format. In particular this will give actions more control over the state and allow external sources to have more control of histedits behavior, e.g. an external implementation of x/exec.
Fri, 17 Oct 2014 02:07:05 +0900 import-checker: check modules for pure Python build correctly
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 17 Oct 2014 02:07:05 +0900] rev 22975
import-checker: check modules for pure Python build correctly Before this patch, "import-checker.py" just replaces "/" in specified filenames by ".". This makes modules for pure Python build belong to "mercurial.pure" package, and prevents "import-checker.py" from correctly checking about cyclic dependency in them. This patch discards "pure" component from fully qualified name of such modules. To avoid discarding "pure" from the module name of standard libraries unexpectedly, this patch allows "dotted_name_of_path" to discard "pure" only from Mercurial specific modules, which are specified via command line arguments.
Fri, 17 Oct 2014 02:07:05 +0900 import-checker: treat "from mercurial import XXXX" style correctly
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 17 Oct 2014 02:07:05 +0900] rev 22974
import-checker: treat "from mercurial import XXXX" style correctly Before this patch, "import-checker.py" assumes that the name of Mercurial module recognized by "imported_modules" doesn't have package part: for example, "util". This is reason why "import-checker.py" always builds fully qualified module name up relatively, if the given module doesn't belong to standard Python library. But in fact, modules imported in "from mercurial import XXXX" style already have fully qualified name: for example, "mercurial.util" module imported by "mercurial.parsers" is treated as "mercurial.mercurial.util" because of building module name up relatively. This prevents "import-checker.py" from correctly checking about cyclic dependency in them. This patch avoids building module name up relatively, also if module name starts with "mercurial.", to treat modules imported in "from mercurial import XXXX" style correctly.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip