sparse: --include 'dir1/dir2' should not include 'dir1/*'
In 2015 there was a workaround added (
f39bace2d6cad32907c0d7961b3c0dbd64a1b7ad)
to sparse in the hg-experimental repo. That workaround:
a) no longer seems to be needed, since its testcase passes even with the code
removed, and
b) caused a new problem: --include 'dir1/dir2' ended up including dir1/*
too. (--include 'glob:dir1/dir2' is a user-level workaround.)
Remove the offending code, and add a testcase for situation B.
fileset: add kind:pat operator
":" isn't taken as a symbol character but an infix operator so we can write
e.g. "path:'foo bar'" as well as "'path:foo bar'". An invalid pattern kind
is rejected in the former form as we know a kind is specified explicitly.
The binding strength is copied from "x:y" range operator of revset. Perhaps
it can be adjusted later if we want to parse "foo:bar()" as "(foo:bar)()",
not "foo:(bar())". We can also add "kind:" postfix operator if we want.
One possible confusion is that the scope of the leading "set:" vs "kind:pat"
operator. The former is consumed by a matcher so applies to the whole fileset
expression:
$ hg files 'set:foo() or kind:bar or baz'
^^^^^^^^^^^^^^^^^^^^^^^^
Whereas the scope of kind:pat operator is narrow:
$ hg files 'set:foo() or kind:bar or baz'
^^^
minifileset: unify handling of symbol and string patterns
They must be identical for fileset compatibility.
fileset: move import of match module to top
Actually there was no circular import issue.
revlog: group delta computation methods under _deltacomputer object
Extracting these methods from revlog will allow changing the implementation of
the deltacomputer, by providing this interface:
__init__(self, revlog) - constructor that initialize the object from a given
revlog
buildtext(self, revinfo, fh) - builds the fulltext version of a revision from
a _revisioninfo object and the file handle to
the .d (or .i for inline mode) file.
finddeltainfo(self, revinfo, fh) - find a revision in the revlog against
which it is acceptable to build a delta,
and build the corresponding _deltainfo.
It should now be easier to write an experimental feature that would replace
_deltacomputer by another object, for example one that would know how to
parallelize the delta computation in order to quicken the storage of multiple
revisions.
revlog: refactor out _finddeltainfo from _addrevision
Splicing the code into smaller chunks should help understanding it,
and eventually override some parts in experimental branches to try
optimization.