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.
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.
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).
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).
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.
The improvement in time complexitty and the speed-up in computation is large
enough that the has little use now. Its update time can even gets in the way. So
we drop it.
This will allow us to unify the static/dynamic blockers logic in the next
changeset.
For a couple of years, we now have precomputed set for all mutable phases. We
can use this set restrict our search and quickly detect non-hideable children of
hideable changesets. This speeds up the hidden computation. See docstring of
the new function for details.
This new version reuses the '_domainancestors' function to keep the computation
of revealed changeset in O(len(visible))
Below are perfvolatilesets timing from two Mozilla repositories with different
contents. hidden cache is disabled while obtaining them.
1) Mozilla repository with:
* 400667 changesets
* 35 hidden changesets (first rev-268334)
* 288 visible drafts
* 1 unstable changeset
Before:
! visible
! wall 0.001744 comb 0.000000 user 0.000000 sys 0.000000 (best of 1563)
After:
! visible
! wall 0.000742 comb 0.000000 user 0.000000 sys 0.000000 (best of 3755)
The timing above include the computation of obsolete changeset:
! obsolete
! wall 0.000396 comb 0.000000 user 0.000000 sys 0.000000 (best of 6816)
So adjusted time give 1.3ms before versus 0.3ms after. A 4x speedup.
2) Mozilla repository with:
* 405645 changesets
* 4312 hidden changesets (first rev-326004)
* 264 visible drafts
* 1 unstable changeset
Before:
! visible
! wall 0.025476 comb 0.030000 user 0.030000 sys 0.000000 (best of 111)
After
! visible
! wall 0.007703 comb 0.010000 user 0.010000 sys 0.000000 (best of 358)
The timing above include the computation of obsolete changeset:
! obsolete
! wall 0.006408 comb 0.010000 user 0.010000 sys 0.000000 (best of 404)
So adjusted time give 19ms before versus 1.3ms after. A 17x speedup.
The complexity of computing the revealed changesets is now 'O(revealed)'.
This massively speeds up the computation on large repository. Moving it to the
millisecond range.
Below are timing from two Mozilla repositories with different contents:
1) mozilla repository with:
* 400667 changesets
* 35 hidden changesets (first rev-268334)
* 288 visible drafts
* obsolete working copy (dynamicblockers),
Before:
! visible
! wall 0.030247 comb 0.030000 user 0.030000 sys 0.000000 (best of 100)
After:
! visible
! wall 0.000585 comb 0.000000 user 0.000000 sys 0.000000 (best of 4221)
The timing above include the computation of obsolete changeset:
! obsolete
! wall 0.000396 comb 0.000000 user 0.000000 sys 0.000000 (best of 6816)
So adjusted time give 30ms before versus 0.2ms after. A 150x speedup.
2) mozilla repository with:
* 405645 changesets
* 4312 hidden changesets (first rev-326004)
* 264 visible drafts
* obsolete working copy (dynamicblockers),
Before:
! visible
! wall 0.168658 comb 0.170000 user 0.170000 sys 0.000000 (best of 48)
After
! visible
! wall 0.008612 comb 0.010000 user 0.010000 sys 0.000000 (best of 325)
The timing above include the computation of obsolete changeset:
! obsolete
! wall 0.006408 comb 0.010000 user 0.010000 sys 0.000000 (best of 404)
So adjusted time give 160ms before versus 2ms after. A 75x speedup.
The contrib/zsh_completion file itself says to name it _hg.
With a name like `hg`, if the user has a line like `autoload ${^fpath}/*(N-.:t)`
in their zshrc, it will create a shell function named `hg` that will hide the
actual hg command and make hg unusable.
Separately from that though, the underscore prefix makes it actually work. The
zsh man page states:
The convention for autoloaded functions used in completion is that they
start with an underscore
This does not seem to just be a "convention", though. With the ill-advised line
removed from my zshrc and the file named
`/usr/local/share/zsh/site-functions/hg` (without the underscore), these
completions did not seem to get loaded and the ones from the zsh installation
were loaded instead. If I renamed them to be
`/usr/local/share/zsh/site-functions/_hg`, however, they were loaded.
I manually tested the above statement by starting a new zsh instance with the
file in `/usr/local/share/zsh/site-functions` with the following names:
- As `hg`, `which _hg_labels` did not show anything
- As `_hg`, `which _hg_labels` showed the expected function.
To quote `man 1 pkgbuild`:
--filter filter-expression
By default, --root will include the entire contents of the
given root-path in the package payload, except for any .svn
or CVS directories, and any .DS_Store files. You can override
these default filters by specifying one or more --filter
options. Each filter-expression is an re_format(7)
``extended'' expression: any path in the root which matches
any of the given expressions will be excluded from the pack-
age payload. (Note that specifying even one --filter inhibits
the default filters, so you must respecify the default fil-
ters if you still want them to be used.)
It turns out the default filter these days *also* includes .git and
.hg. Notice how that filter expression is a regular expression? That
(presumably unintentionally) prevents a file named "chg" or "_hg" from
getting included in the distribution. Many many thanks to spectral@
for trying to include a _hg file which led us to figure this bug out.
Bug filed with Apple for this as rdar://problem/32437369, mentioning
both the gap in documentation and the wrong defaults.
As I've said on earlier patches, I'm hoping to use more composition of
simpler matchers instead of the single complex matcher we currently
have. This extracts a first new matcher that composes two other
matchers. It matches if the first matcher matches but the second does
not. As such, we can use it for excludes, which this patch also
does. We'll remove the now-unncessary code for excludes in the next
patch.
d46a7814be5f refactored util.parsedate in order to raise ValueError instead
of Abort for using with ui.configwith. It causes several problems, putting
arbitrary bytes in ValueError can cause issues with Python 3. Moreover, we
added a function to convert ValueError exceptions back to Abort.
A better approach would be to make parsedate raises ParseError, removing
the convert function and update configwith to also catch ParseError.
The side-effect is that error message when giving an invalid date in CLI
change from:
abort: invalid date: 'foo bar'
to:
hg: parse error: invalid date: 'foo bar'
I'm not sure if it's an acceptable change, I found personally the error
message more clear but more verbose too.
I'm hoping to rewrite the matcher so excludes are handled by
composition of one matcher with another matcher where the second
matcher has only includes. For that to work, we need to make
visitdir() to return 'all' for directory 'foo' for a '-I foo' matcher.
This makes the subdirmatcher not depend on the main matcher, giving us
more freedom to modify that (specifically, it will lose it _always
field in a while).
We will soon start splitting up the current matcher class into more
specialized classes, so we'll want a base class for all the things
that don't vary much between different matchers.
The function use the length of the repository, something affected by filtering.
It seems better to use the unfiltered length here.
Credit for finding this goes to Durham Goode.
I just burned myself on this today because I left out the -r in my `hg
bookmark` command, which then left me confused because I didn't notice
the bookmark I created in the wrong place that was silently shadowing
the revision I was trying to check out. Let's warn the user.
This patch only enforces the check on bookmark names 4 characters long
or longer. We can tweak that if we'd like, I selected that since
that's the fewest characters shortest will use in the templater
output.
A previous version of this patch rejected such bookmarks. It was
proposed during review (and I agree) that the behavior change for a
bookmark named "cafe" or similar as history accumulated was a little
too weird, but that the warning definitely has merit.
d46a7814be5f introduced util._parsedate with the aim to be used in
ui.configdate but ui.configdate was using util.parsedate instead. It have the
impact of raising an AbortError in case of an invalid date instead of a
ConfigError exception. Fix ui.configdate to use the right function and add a
test for invalid dates.
Thanks to Yuya for the catch!
When we try to run, 'hg debugrevspec 'branch(wdir())'', it throws an index error
and blows up. Lets raise the WdirUnsupported if wdir() is passed so that we can
catch that later.
For wdir(), we now raises an exception which will be raised when wdir() will be
passed, so catching that exception is better checking for wdir() using if-else.
