This is all pure-Python code, so I'm not too worried about perf here,
but we can come back and fix it should it be a problem.
With this change, the manifest code passes most unit tests on Python 3
(once the tests are corrected with many b prefixes. I've got a little
more to sort out there and then I'll mail that change too.
This fixes `hg files 'set:(**.py)'` which makes test-check-py3-compat.t able to
run on Python 3. So if you now do `python3 ./run-tests.py
test-check-py3-compat`, the test will actually run.
This will make sure when ctx.repo.manifestlog changes, a correct new
manifestctx is returned. repo.manifestlog takes care of caching so the
manifestctx won't be reconstructed every time.
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.
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.)
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.
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.
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.
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).
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/).
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.
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).
In upcoming patches we'll need to be aware of all parents at the same time.
This also exposes a potential bug: if a line can be annotated with both parents
of a merge commit, it'll always be annotated with p2, not p1. I'm not sure if
that's what we want, but at least the code makes it clear now.
'mark in repo' may raise LookupError. I set it to not be warned since bookmark
names shorter than 4 chars aren't checked and short names are likely to be
ambiguous.
