Sun, 28 May 2017 11:50:43 -0700 bundle: add an experimental knob to include obsmarkers in bundle
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 28 May 2017 11:50:43 -0700] rev 32516
bundle: add an experimental knob to include obsmarkers in bundle The "hg bundle" command is a good place to test if the inclusion of obsmarkers within a bundle is working well (part exists, content is correct etc). So we add a way to have them included. Ideally, this would be controlled by a change around bundlespec (bundlespec "v3" + arguments). However, my main goal is to have obsmarkers included in bundle created by the 'hg strip' command, not the 'hg bundle' so for now I'm avoiding the detour through bundlespec rework territory. Better debug output for obsmarkers in 'debugbundle' will be added in later changesets. The 'test-obsolete-bundle-strip.t' test will also get updated in a later changeset to keep the current changeset smaller.
Sun, 28 May 2017 11:48:18 -0700 bundle2: move function building obsmarker-part in the bundle2 module
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 28 May 2017 11:48:18 -0700] rev 32515
bundle2: move function building obsmarker-part in the bundle2 module We move it next to similar part building functions. We will need it for the "writenewbundle" logic. This will allow us to easily include obsmarkers in on-disk bundle, a necessary step before having `hg strip` also operate on markers. (Yes, the bundle2 module was already too large, but there any many interdependencies between its components so it is non-trivial to split, this is a quest for another adventure.)
Tue, 02 May 2017 21:45:48 +0900 policy: remove unused policynoc and policynocffi constants
Yuya Nishihara <yuya@tcha.org> [Tue, 02 May 2017 21:45:48 +0900] rev 32514
policy: remove unused policynoc and policynocffi constants
Tue, 02 May 2017 21:45:10 +0900 cffi: remove superfluous "if True" blocks
Yuya Nishihara <yuya@tcha.org> [Tue, 02 May 2017 21:45:10 +0900] rev 32513
cffi: remove superfluous "if True" blocks
Tue, 02 May 2017 21:15:31 +0900 cffi: split modules from pure
Yuya Nishihara <yuya@tcha.org> [Tue, 02 May 2017 21:15:31 +0900] rev 32512
cffi: split modules from pure The copyright lines are updated per change history. cffi/osutil.py isn't tested since I have no access to OS X machine right now, sorry.
Sun, 28 May 2017 15:45:52 +0900 policy: extend API version checks for cffi
Yuya Nishihara <yuya@tcha.org> [Sun, 28 May 2017 15:45:52 +0900] rev 32511
policy: extend API version checks for cffi This is just a stub for future extension. I could add a version constant to CFFI modules by putting it to both ffi.set_source() and ffi.cdef(), but that doesn't seem right. So for now, cffi modules will be explicitly unversioned (i.e. version constant must be undefined or set to None.) We can revisit it later when we need to consider CFFI support more seriously.
Sun, 28 May 2017 17:36:01 +0900 filterpyflakes: allow reexporting pure symbols from cffi modules
Yuya Nishihara <yuya@tcha.org> [Sun, 28 May 2017 17:36:01 +0900] rev 32510
filterpyflakes: allow reexporting pure symbols from cffi modules cffi modules will do 'from ..pure.<module> import *'.
Tue, 02 May 2017 22:28:18 +0900 import-checker: guess names of C extension modules
Yuya Nishihara <yuya@tcha.org> [Tue, 02 May 2017 22:28:18 +0900] rev 32509
import-checker: guess names of C extension modules Since extension modules aren't included in the list of source files, they need to be populated somehow. Otherwise the import from cext/cffi would be treated as a global one.
Sun, 28 May 2017 15:21:18 +0900 import-checker: convert localmods to a set of module names
Yuya Nishihara <yuya@tcha.org> [Sun, 28 May 2017 15:21:18 +0900] rev 32508
import-checker: convert localmods to a set of module names This makes it easy to add a source-less module name to the set.
Tue, 02 May 2017 22:24:57 +0900 import-checker: allow importing symbols from pure modules
Yuya Nishihara <yuya@tcha.org> [Tue, 02 May 2017 22:24:57 +0900] rev 32507
import-checker: allow importing symbols from pure modules This allows us to re-export pure functions from cffi modules: # mercurial/cffi/base85.py from ..pure.base85 import *
Tue, 02 May 2017 21:08:38 +0900 cffi: put compiled modules into mercurial.cffi package
Yuya Nishihara <yuya@tcha.org> [Tue, 02 May 2017 21:08:38 +0900] rev 32506
cffi: put compiled modules into mercurial.cffi package Don't pollute the top-level namespace.
Tue, 02 May 2017 21:04:40 +0900 cffi: rename build scripts
Yuya Nishihara <yuya@tcha.org> [Tue, 02 May 2017 21:04:40 +0900] rev 32505
cffi: rename build scripts This frees up cffi package for modules to be split from pure.
Fri, 19 May 2017 11:44:05 -0700 match: remove support for includes from patternmatcher
Martin von Zweigbergk <martinvonz@google.com> [Fri, 19 May 2017 11:44:05 -0700] rev 32504
match: remove support for includes from patternmatcher Includes (and excludes) are now delegated to the includematcher.
Mon, 22 May 2017 23:31:15 -0700 match: simplify includematcher a bit
Martin von Zweigbergk <martinvonz@google.com> [Mon, 22 May 2017 23:31:15 -0700] rev 32503
match: simplify includematcher a bit The "include" we have in symbols is redundant and the double negative in visitdir() can be removed.
Fri, 19 May 2017 13:36:34 -0700 match: remove support for non-include patterns from includematcher
Martin von Zweigbergk <martinvonz@google.com> [Fri, 19 May 2017 13:36:34 -0700] rev 32502
match: remove support for non-include patterns from includematcher The includematcher will always get at least one include pattern and will never get any non-include patterns, so we can remove most of the code in it. This patch does mostly straight-forward deletions of code. We will clean up further later.
Fri, 19 May 2017 22:36:14 -0700 match: split up main matcher into patternmatcher and includematcher
Martin von Zweigbergk <martinvonz@google.com> [Fri, 19 May 2017 22:36:14 -0700] rev 32501
match: split up main matcher into patternmatcher and includematcher At this point the includematcher is an exact copy of the main matcher class. We will specialize and simplify both classes in the following patches. This initial unmodified copy is just to make the differences clearer. We also rename the main matcher to "patternmatcher" for consistency. I may eventually merge this new includematcher back into the main matcher, but I think doing it this way makes the intermediate steps clearer regardless.
Thu, 18 May 2017 23:39:39 -0700 match: remove support for exact matching from main matcher class
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 May 2017 23:39:39 -0700] rev 32500
match: remove support for exact matching from main matcher class Exact matching is now handled by the exactmatcher class. We can safely remove _files from the __repr__() implementation, because even though the field is set, the patternspat field is enough for the representation to be unambiguous (which was not the case when the matcher could handle exact matches).
Wed, 17 May 2017 09:26:15 -0700 match: handle exact matching using new exactmatcher
Martin von Zweigbergk <martinvonz@google.com> [Wed, 17 May 2017 09:26:15 -0700] rev 32499
match: handle exact matching using new exactmatcher
Fri, 12 May 2017 16:33:33 -0700 merge: use intersectmatchers() in "m2-vs-ma optimization"
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 May 2017 16:33:33 -0700] rev 32498
merge: use intersectmatchers() in "m2-vs-ma optimization" It doesn't seem like this can actually happen, but seems like cleaner anyway.
Fri, 12 May 2017 23:12:05 -0700 match: handle includes using new intersectionmatcher
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 May 2017 23:12:05 -0700] rev 32497
match: handle includes using new intersectionmatcher
Thu, 25 May 2017 14:32:56 -0700 match: move entire uipath() implementation to basematcher
Martin von Zweigbergk <martinvonz@google.com> [Thu, 25 May 2017 14:32:56 -0700] rev 32496
match: move entire uipath() implementation to basematcher Even though most matchers will always want to use the relative path in uipath(), when we add support for intersecting matcher, we will want to control which form to use for any kind of matcher without knowing the type (see next patch), so we need the implementation on the base class. Also rename the attribute from "pathrestricted" to "relativeuipath" since there actually are cases where we match everything but still use relative paths (like when the user runs "hg files .." from inside mercurial/).
Thu, 25 May 2017 12:09:09 +0200 local-clone: also copy tags related caches
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 25 May 2017 12:09:09 +0200] rev 32495
local-clone: also copy tags related caches This caches provide a large speedup for some repositories. Keeping it around is valuable.
Thu, 25 May 2017 12:05:33 +0200 local-clone: also copy revs-branch-cache files
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 25 May 2017 12:05:33 +0200] rev 32494
local-clone: also copy revs-branch-cache files This cache provides a large speedup for some repositories. Keeping it around is valuable.
Thu, 25 May 2017 11:59:07 +0200 local-clone: extract the listing of caches to copy
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 25 May 2017 11:59:07 +0200] rev 32493
local-clone: extract the listing of caches to copy Right now, the clone only copies the branchmap caches. There are multiple other valuable caches that we should copy and extensions might add their own. So we add a function to list the cache files to copy from the repository. The repository argument is unused but extensions will want it.
Thu, 25 May 2017 11:55:00 +0200 local-clone: extract the closure copying caches
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 25 May 2017 11:55:00 +0200] rev 32492
local-clone: extract the closure copying caches Closures often get on the way. They are not much value in having that as a closure so I'm extracting it at the module level.
Thu, 25 May 2017 19:38:00 +0200 test: add isolated prune case (to test-obsolete-bundle-strip.t)
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 25 May 2017 19:38:00 +0200] rev 32491
test: add isolated prune case (to test-obsolete-bundle-strip.t) This adds a test where the prune marker is not related to any other obsmarkers.
Thu, 25 May 2017 19:37:47 +0200 test-obsolete-bundle-strip: add a complex split and fold case
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 25 May 2017 19:37:47 +0200] rev 32490
test-obsolete-bundle-strip: add a complex split and fold case This is a more complex case that checks the logic used when split and fold gets into play.
Thu, 25 May 2017 19:37:29 +0200 test-obsolete-bundle-strip: add cases with prune on missing revs
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 25 May 2017 19:37:29 +0200] rev 32489
test-obsolete-bundle-strip: add cases with prune on missing revs Same as the previously added case, but the prune is no longer known locally. This will mostly matter for the strip testing. Introducing the test early will help clarify patches related to strip.
Thu, 25 May 2017 19:37:29 +0200 obsolete: fix relevant-obsmarkers computation on pruned changeset
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 25 May 2017 19:37:29 +0200] rev 32488
obsolete: fix relevant-obsmarkers computation on pruned changeset The markers pruning a node was not directly considered relevant for the pruned node, only to its parents. This went unnoticed during obsmarkers exchange because all ancestors of the pruned node would be included in the computation. This still affects obsmarkers exchange a bit since "inline" prune markers would be ignored (see second test case). This went unnoticed, because in such case, we always push another obsolescence markers for that node. We add explicit tests covering this case. (The set of relevant changeset is use in the obsmarkers discovery protocol used in the evolve experimental extension, the impact will be handled on the extension side).
Thu, 25 May 2017 19:37:07 +0200 test: add a test file for relevant obsmarkers and its usage
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 25 May 2017 19:37:07 +0200] rev 32487
test: add a test file for relevant obsmarkers and its usage The logic around obsmarkers "relevant" to a set of revs have a couple of test around in other places but no systematic testing. In addition, all the current testing focus on the exchange case (we looks at relevant markers for '::heads'). For bundles, we'll need something a bit different. We'll no longer have set of revision going down to the repository roots. So we'll have to test these cases too. In addition, stripping obsmarkers will introduce new logic around obsmarkers that will need testing too. So a new test file make sense here. We start with a simple tests, more advanced cases are coming in the next changesets. The extra testing catch a minor bug (later in the series).
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip