When dropping files from the dirstate, the corresponding entry in the
filefoldmap is also dropped. Move this into the dirstate map object. A future
implementation of the dirstate will maintain the filefoldmap differently.
Differential Revision: https://phab.mercurial-scm.org/D1343
The dirstate dirs object is owned by the map, so move management of that object
there. A future implementation of the dirstate will manage the dirs object
differently.
Differential Revision: https://phab.mercurial-scm.org/D1342
The dirstate map owns the nonnormal sets, and so should be the class to update
them. A future implementation of the dirstate will manage these maps
differently.
The action of clearing ambiguous times is now entirely controlled by the
dirstate map, so it moves there too.
Differential Revision: https://phab.mercurial-scm.org/D1341
Instead of assigning dirstatetuple objects to entries in the dirstate, move
responsibility for creating tuples into the dirstatemap.
Differential Revision: https://phab.mercurial-scm.org/D1340
Strictly speaking, this variable tracks offsets within the
changegroup, not the bundle.
While we're here, mark a class attribute as private because
it is.
.. api::
Rename bundlerepo.bundlerepository.bundlefilespos to
_cgfilespos.
Differential Revision: https://phab.mercurial-scm.org/D1384
"bundle" was appropriate for the bundle1 days where a bundle
was a changegroup. In a bundle2 world, changegroup readers
are referred to as "changegroup unpackers."
Differential Revision: https://phab.mercurial-scm.org/D1383
3649c3f2cd (revert: do not reverse hunks in interactive when REV is not
parent (issue5096)) changed the record "operation" for the text version but
missed the curses version. Without this patch, running
`hg revert -ir '.^' --config ui.interface=curses` would crash with:
ProgrammingError: unexpected operation: apply
Differential Revision: https://phab.mercurial-scm.org/D1381
In spartan theme phase is shown on its own table row, because there's no single
line of "tags". Everywhere else phase is prepended to the list of "tags" of a
changeset. Its element has a purple-ish color in gitweb and monoblue, and a
dotted line under it and no color in paper and coal (as these themes are frugal
with colors).
This patch intentionally doesn't touch graph, because it needs a rewrite. I'll
get to it pretty soon and in the process will add phase and everything that's
still coming (e.g. obsolescence and instabilities).
.. feature::
hgweb now displays phases of non-public changesets
This patch puts all these changeset "tags" into one template shared everywhere
in paper and coal themes. But it should be noted that some of the templates had
different sets of tags, in some cases it was intended, in others - most likely
not.
First, what's up with all these different ways to get changeset's branch. There
are actually 3 ways to do it in hgweb, they can all be seen in this patch;
"branches", "inbranch" and "branch". They are all lists that consist of 1 or 0
items:
- "branches" has ctx.branch() if current changeset is the tip of that branch
- "inbranch" has ctx.branch() if current changeset is _not_ the tip of that
branch and the branch is not "default"
- "branch" aka "changesetbranch" has ctx.branch() if the branch is not
"default"
The majority of cases (7 vs 2 + /graph) in paper theme used only option 3,
which meant that "default" was never displayed. But other parts of the theme
disagreed with this and used option 1 and option 2 together. For example, the
default view (log) displays "default" on the branch tip (can be seen right
about now on m-s.o/repo/hg), but it disappears when you click on the commit.
Also, using option 3 alone meant that there was no way to tell if a changeset
is the tip of its branch or not (it was always assumed that it's not, see how
some css classes change from "branchname" to the correct "branchhead" in tests)
-- so the two different css styles that exist in paper just for this were
underused.
I think this patch improves the situation, even though it changes the old (even
if inconsistent) behavior. The new behavior matches that of gitweb and
monoblue.
I'd like to call the function from an extension, passing both "strip"
and "prefix", but it currently only accepts "strip". The only in-tree
caller seems to be mq.py, which doesn't even pass "strip".
Differential Revision: https://phab.mercurial-scm.org/D1413
Less duplication and it's also easier to add extra "tags" everywhere at once.
These aren't tags as defined `hg help glossary` (hence the quotes), they are
simply called that. They include branch name (in different styles if changeset
is a head of that branch or not), (actual) tags and bookmarks. Good candidates
to add to this list would be changeset phase and obsoletion status.
It is a bit wonky to assign the same object to multiple
attributes and then possibly overwrite them later.
Refactor the code to use a local variable and defer attribute
assignment until the final values are ready.
This required passing the bundle instance to _handlebundle2part().
The only use of this method I could find is Facebook's
treemanifest extension. Since it is a private method, I don't
think it warrants an API callout.
Differential Revision: https://phab.mercurial-scm.org/D1378
These attributes are implementation details and shouldn't be
exposed outside the class.
.. api::
bundlerepo.bundlerepository.bundle and
bundlerepo.bundlerepository.bundlefile are now prefixed with an
underscore.
Differential Revision: https://phab.mercurial-scm.org/D1377
exchange.readbundle() can return a type that represents a stream
clone bundle. Explicitly handle the bundle1 type and raise a
reasonable error message for unhandled bundle types.
Differential Revision: https://phab.mercurial-scm.org/D1376
It looks like the refactor in 0883a2ece555 attempted to establish
this method argument but failed to use it. My editor caught it.
Differential Revision: https://phab.mercurial-scm.org/D1373
My editor was complaining about mismatches between method
signatures.
For methods that are implemented, we change arguments to match
the base. For those that aren't, we use variable arguments
because it shouldn't matter.
Differential Revision: https://phab.mercurial-scm.org/D1372
Constants make code easier to read than magic numbers.
I also threw in an explicit argument in a caller to further
increase code comprehension.
Differential Revision: https://phab.mercurial-scm.org/D1370
This is a short topic to explain how command-line flags can be specified.
Some users have been confused by hg offerring different flag syntax than some
other libraries, so it'd be nice to point them to this rather than explaining
it every time.
Differential Revision: https://phab.mercurial-scm.org/D1270
Everything is pretty self-explanatory except the last hunk, where jshint
complains: "Misleading line break before '||'; readers may interpret this as an
expression boundary."
There is a tweakable called "laxbreak" that allows line breaks before
operators, but I think it's fine to simply join this one line and avoid extra
config for now (we can cook up and add a sensible .jshintrc later).
The internal representation of bookmark value is binary. The fact we stored
'hex' was an implementation detail from using pushkey.
We move the values in 'pullop.remotebookmarks' to binary before adding a way to
exchange bookmarks not based on pushkey.
These new colors and styles are already used in the tooltip that gets shown
when user hovers over line numbers on annotate page. The old styles, replaced
in this patch, look completely unrelated to gitweb or any other hgweb theme.
These new colors and styles are already used in the tooltip that gets shown
when user hovers over line numbers on annotate page. The old styles, replaced
in this patch, look completely unrelated to paper or any other hgweb theme.
The dirstate typically tries to keep the nonnormalset and otherparentset
up-to-date when making changes to the dirstate. In the case of files marked
normallookup, however, it erroneously removes the file from the nonnormalset,
after _addpath had just added it.
This doesn't seem to matter at the moment, as nothing relies on the
nonnormalset being correct at this point, however a future re-implementations
of the dirstate map will require this to be kept up-to-date correctly.
Differential Revision: https://phab.mercurial-scm.org/D1339
dirstatemap.clear should remove all record of the files in the map. This
includes removing caches of values derived from these.
Differential Revision: https://phab.mercurial-scm.org/D1338
This utility function allows clearing of the cached value set up
@propertycache, if there is one.
Differential Revision: https://phab.mercurial-scm.org/D1337
This is fixing quadratic behavior, which is probably not noticeable in the
common case, but if a very large directory gets added here, it can get pretty
bad. This was noticed because we had some pushes that spent >25s in changegroup
generation calling min() here, according to profiling.
The original reasoning for min() being used in 1d71430e1d28 was that, at that
point in the series, we were adding almost everything to tmfnodes during the
first iteration through the loop , so we needed to avoid sending child
directories before parents. Later changes made it so that the child directories
were added only when we visited the parent directory (not all of them on the
first iteration), so this is no longer necessary - there won't be any child
directories in tmfnodes before the parents have been sent.
This does mean that the manifests are now exchanged unordered, whereas
previously we would essentially do [a, b, b/c, b/c/d, e], we now can send a, b,
and e in any order; b/c must still follow b, and b/c/d must still follow b/c.
Differential Revision: https://phab.mercurial-scm.org/D1351
With our treemanifest logic, the manifests are no longer transported as part of
the changegroup and are no longer stored in a revlog. This means the
self.manifestlog line in bundlerepo.filestart no longer calls
_constructmanifest, and therefore does not consume the manifest portion of the
changegroup, which means filestart is not populated and we result in an infinite
loop.
The fix is to make filestart aware that self.manifestlog might not consume the
changegroup part, and consume it manually if necessary.
There's currently no way to test this in core, but our treemanifest extension
has tests to cover this.
Differential Revision: https://phab.mercurial-scm.org/D1329
When origbackuppath is set, when looking to see if a file we are backing up
conflicts with a directory in the origbackuppath, we incorrectly match on
symlinks to directories. This means we try to call vfs.rmtree on the
symlink, which fails.
Differential Revision: https://phab.mercurial-scm.org/D1311
We change subrepos.allowed from a list of allowed subrepo types to
a combination of a master switch and per-type boolean flag.
If the master switch is set, subrepos can be disabled wholesale.
If subrepos are globally enabled, then per-type options are
consulted. Mercurial repos are enabled by default. Everything else
is disabled by default.
These config items control share behavior that is implemented in core.
Since the functionality is implemented in core, extensions may
leverage it.
Mozilla has one such extension. And, it needs to access share.pool.
Before this patch, a devel warning regarding accessing an unregistered
config option would be issued unless the share extension were loaded.
Moving the registration of the config options to core fixes this.
We have a security issue with git subrepos. I'm not sure if svn subrepo is
vulnerable, but it seems not 100% safe to allow writing arbitrary data into
a metadata directory. So for now, only hg subrepo is enabled by default.
Maybe we should improve the help to describe why git/svn subrepos are
disabled.
This allows us to minimize the behavior change introduced by the next patch.
I have no idea which config style is preferred in UX POV, but I decided to
get things done.
a) list: 'allowed = hg, git, svn'
b) sub option: 'allowed.hg = True' or 'allowed:hg = True'
c) per-type action: 'hg = allow', 'git = abort'
This is an alternative workaround for the issue5730.
Perhaps this is the simplest way of disabling subrepo operations. It does
nothing clever, but just aborts if Mercurial starts accessing to a subrepo.
I think Greg's patch is more useful since it allows us to at least check
out the parent repository. However, that would be confusing if the default
is flipped to checkout=False and subrepos are silently ignored.
I don't like the config name 'allowed', but I couldn't get any better name.
Previously, if there were unresolved files and the CWD drive was different from
the repo drive, `hg status -v` would page the normal status, followed by the
exception header. A stacktrace was waiting when the pager exited. The
underlying cause was the same as 12441ef4442f.
Unfortunately, I don't see any reasonable way to write a test this [1].
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-November/107401.html
This is a followup to 12441ef4442f. Since there's no way to ensure that more
drive letters than C: exist, this seems like the only way to test it. This is
enough to catch the 12441ef4442f scenario, as well as CWD outside of the repo
when the path isn't prefixed with path/to/repo.
It wasn't easy to extend the pathauditor to check symlink traversal across
subrepos because pathauditor._checkfs() rejects a directory having ".hg"
directory. That's why I added the explicit islink() check.
No idea if this patch is necessary after we've fixed the issue5730 by
splitting submerge() into planning and execution phases.
os.path.relpath() exploded if the 'root' and 'cwd' directories had different
drive letters. I noticed this in TortoiseHg when typing a fileset into the
filter, and it kept complaining until the closing '()' was typed. This was
reproducible on the command line with:
$ cd /d
$ hg -R /c/Users/Matt/Projects/hg files 'set:e'
Traceback (most recent call last):
...
File "mercurial\pathutil.pyc", line 182, in canonpath
File "ntpath.pyc", line 529, in relpath
ValueError: path is on drive c:, start on drive d:
The original condition was a bit harsh for extension authors since third-party
extensions need to preserve compatibility with older Mercurial versions, where
no defaults would be loaded from the configtable. So let's silence the warning
if the given default value matches, which should be harmless.
After a refactoring, _toolstr stopped having default="" as one of it's args,
therefore when called without a default it returns None and not "". This causes
concatenation to fail.
We've found a severe perf regression in `hg update` caused by the path conflict
checking code. The next patch will disable this by default.
Differential Revision: https://phab.mercurial-scm.org/D1222
When a dirstate backup is restored, it is possible that no actual changes to
the dirstate have been made. In this case, the backup is still a hardlink
to the original dirstate.
Unfortunately, `os.rename` silently fails (nothing happens, and no error
occurs) when `src` and `dst` are hardlinks to the same file. As a result,
the backup is left lying around. Over time, these files accumulate.
When restoring dirstate backups, check if the backup and the dirstate are
the same file, and if so, just delete the backup.
Differential Revision: https://phab.mercurial-scm.org/D1201
A recent refactor added a layer of abstraction to the dirstate which makes doing
things like 'foo in dirstate' now require some extra Python attribute lookups.
This is causing a 100ms slow down in hg status for mozilla-central.
The fix is to hoist the inner dict's functions onto the main class once the lazy
loading it complete, as well as store the actual functions before doing the
status loop (as is done for other such functions).
In my testing, it seems to address the performance regression, but we'll
need to see the perf run results to know for sure.
Differential Revision: https://phab.mercurial-scm.org/D1257
Before the recent refactor, we would not load the entire map until it was
accessed. As part of the refactor, that got lost and even just trying to load
the dirstate parents would load the whole map. This caused a perf regression
(issue5713) and a regression with static http serving (issue5717).
Making it lazy loaded again fixes both.
Differential Revision: https://phab.mercurial-scm.org/D1253
A future diff will move the lazy loading aspect of dirstate to the dirstatemap
class. This means it requires a slightly different strategy of clearing than
just reinstantiating the object (since just reinstantiating the object will
lazily load the on disk data again later instead of remaining permanently
empty).
So let's give it it's own clear function.
Differential Revision: https://phab.mercurial-scm.org/D1252
The same applies to '?' if --quiet is used (or any of the other states if some
of -marduic is specified), but I couldn't figure out how to express that
clearly.
This seems a bit hacky, but works well. There should be no reason that
static-http repo had to load dirstate.
Initially I tried to proxy os.stat() call through vfs so that statichttpvfs
could hook it, but there wasn't a good error value which the statichttpvfs
could return to get around the util.filestat issue.
Right now, successorsetverb only needs successors to compute the verb. But we
will want use additional information (effect-flags and operation) in the near
future to compute a better verb.
Add the markers parameter now so extensions (like Evolve) could wrap the
function and start experimenting around better obsfate verbs.
As successorsetverb now takes both successorset and markers parameters, rename
it to obsfateverb, successorsetandmarkersverb was too long.
Differential Revision: https://phab.mercurial-scm.org/D1191
Previously, the caller was responsible for creating the directory structure of
files written out using a path template. This is onerous, especially if the
exact filenames are not known upfront, but are being accessed via a matcher.
This patch changes things so that hg will attempt to create the appropriate
directories before writing the output file.
Differential Revision: https://phab.mercurial-scm.org/D1332
And introduce a new "apply" operation verb for this case as suggested in
issue5096. This replaces the no longer used "revert" operation.
In interactive revert, when reverting to something else that the parent
revision, display an "apply this change" message with a diff that is not
reversed.
The rationale is that `hg revert -i -r REV` will show hunks of the diff from
the working directory to REV and prompt the user to select them for applying
(to working directory). This contradicts 79cc693b4406 in which it was
decided to have the "direction" of prompted hunks reversed. Later on
[1], there was a broad consensus (but no decision) towards the "as to
be applied direction". Now that --interactive is no longer experimental
(97d754ba45c4), it's time to switch and thus we drop no longer used
"experimental.revertalternateinteractivemode" configuration option.
[1]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-November/090142.html
.. feature::
When interactive revert is run against a revision other than the working
directory parent, the diff shown is the diff to *apply* to the working directory,
rather than the diff to *discard* from the working copy. This is in line with
related user experiences with `git` and appears to be less confusing with
`ui.interface=curses`.
The short options "-c" and "-C" may be confusing for a novice reading the
documentation. Let's try to be more explicit, also mentioning the equivalent
long options ("--check" and "--clean") in the comments.
Currently, specifying both a line-range pattern and a bare file pattern
results in an AND operation whereas we probably want an OR so that bare file
patterns are like a line-range pattern with all lines specified.
So, until this works as expected, we disable this.
When a file is binary patch.trydiff() would yield None for 'hunkrange'. Handle
this case in the hunksfilter() callback.
Add tests with and without diff.git option as binary handling differs
depending on this option's value.
Effect-flags config was in flight while the previous evolve config renaming
was written. Now that both landed, gather effect-flags in
experimental.evolution like the others evolve-related configurations.
Differential Revision: https://phab.mercurial-scm.org/D1197
Yuja's comment on the original obsfate about how we would translate obsfate
and the recent discussions about exposing users to new concepts and names lead
have led me to think that 'obsfate' should be treated as internal jargon. End-
users should not be aware of obsfate, so we replace 'obsfate' by 'obsolete' in
changeset_printer.
It will be easier to understand for end-users, easier to translate and closer
to the original Evolve obsfate output.
I'm aware it's extremely late in the cycle but I think it's an UX improvement
for the end-users.
Differential Revision: https://phab.mercurial-scm.org/D1189
An empty entry in the revlog may happen for two reasons:
- when the file is empty, and the revlog stores a snapshot;
- when there is a merge and both parents were identical.
`hg debugindex -m | awk '$3=="0"{print}' | wc -l` gives 1917 of such entries
in my clone of pypy, and 113 on my clone of mercurial.
These empty revision may be located at the end of a sparse chain, and in some
special cases may lead to read relatively large amounts of data for nothing.
