The acl extension is usually setup through hooks and never directly activated.
This means the config item declared in the extension are not loaded.
We add the necessary logic to make sure the extensions are loaded before the hook
run.
We register the merge-tools config section (which has an arbitrary base config
value) and the possible sub-attribute. The sub-attribute has to be registered
first or at the same time otherwise the '.*' item would shadow them.
Merge tools could include "." in their name so we can't constrain any more
than just ".*".
Delta chains can become quite sparse if there is a lot of unrelated data between
relevant pieces. Right now, revlog always reads all the necessary data for the
delta chain in one single read. This can lead to a lot of unrelated data to be
read (see issue5482 for more details).
One can use the `experimental.maxdeltachainspan` option with a large value
(or -1) to easily produce a very sparse delta chain.
This change introduces the ability to slice the chunks retrieval into multiple
reads, skipping large sections of unrelated data. Preliminary testing shows
interesting results. For example the peak memory consumption to read a manifest
on a large repository is reduced from 600MB to 250MB (200MB without
maxdeltachainspan). However, the slicing itself and the multiple reads can have
an negative impact on performance. This is why the new feature is hidden behind
an experimental flag.
Future changesets will add various parameters to control the slicing heuristics.
We hope to experiment a wide variety of repositories during 4.4 and hopefully
turn the feature on by default in 4.5.
As a first try, the algorithm itself is prone to deep changes. However, we wish
to define APIs and have a baseline to work on.
When a merge commit creates an empty diff in the revlog, its offset may still
be quite far from the end of the previous chunk.
Skipping these empty chunks may reduce read size significantly.
In most cases, there is no gain, and in some cases, little gain.
On my clone of pypy, `hg manifest` reads 65% less bytes (96140 i/o 275943) for
revision 4260 by ignoring the only empty trailing diff.
For revision 2229, 35% (34557 i/o 53435)
Sadly, this is difficult to reproduce, as hg clone can make its own different
structure every time.
Move the logic to build bundle2 pushkey part into its dedicated function. It
will help to keep the logic clear when adding support for sending phases change
using 'phase-heads' part.
We are about to switch phase pushing from using pushkey to using a the new
dedicated binary part. We introduce the push race detection on its own to help
detect potential impact.
This part checks if revisions are still in the same phase as when the
bundle was generated. This is similar to what 'check:heads' or
'check:updated-heads' bundle2 part achieves for changesets.
We needs seems before we can move away from pushkey usage from phase since
pushkey has it own built-in push-race detection.
This comment is about:
issue3781: Courtesy Phases synchronisation to publishing server prevent
subrepo push
Not about:
issue3871: Slow hg log when template contains {file_adds}, {file_mods} and
{file_dels}
The on-disk file can contain draft root that are descendants of secret root.
The resulting phase computation is correct, but the phases root content is
not. I will send another series to introduce code that remove some of the
cases where this can happens, but we first need to damage control the existing
case.
After this changeset, we can no longer advertise secret changeset as draft
root.
Previously, only the top level repo was shared, and then any subrepos were
cloned on demand. This is problematic because commits to the parent repo would
write an updated .hgsubstate to the share source, but the corresponding subrepo
commit would be stuck in the local subrepo. That would prevent an update in the
source repo. We already go to great lengths to avoid having inconsistent repos
(e.g., `hg push -r rev` will push _everything_ in a subrepo, even if it isn't
referenced in one of the parent's outgoing commits). Therefore, this seems like
a bug fix, and there's no option to get the old behavior. I can't imagine the
previous behavior was useful to anybody.
There shouldn't be an issue with svn, since it is centralized. Maybe --git-dir
can be used for git subrepos, but I'll leave that to someone more familiar with
git.
An integer was previously being implicitly returned from commands.share(), which
caused dispatch() to start crashing when changing over to returning the shared
repo. All error paths appear to raise, so this can be hardcoded to success.
The clone command checks for 'is None' in a similar pattern, but since
hg.clone() always returns a tuple, that seems wrong?
.. fix:: Issue 5675
Creating a share of a repository with a Mercurial subrepository will now
share the subrepository.
and
.. bc::
Mercurial subrepositories are now shared instead of cloned when the parent
repository is shared. This prevents dangling subrepository references in the
share source. Previously shared repositories with cloned subrepositories
will continue to function unchanged.
This will help us in determining easily that whether fuzzywuzzy is loaded or not
loaded in any of the function.
Differential Revision: https://phab.mercurial-scm.org/D1120
While producing releasenotes for (4.3::), releasenotes aborts with error because
of some bad formatting of releasenotes in some commits. Instead of aborting,
this adds warning message which will help us in skipping them and telling user
about it.
Differential Revision: https://phab.mercurial-scm.org/D1097
If fuzzywuzzy is note present, we will not be having the capability to merge
existing releasenotes with the new releasenotes on the similarity basis.
The merging will still work good for exact same releasenotes entries.
Differential Revision: https://phab.mercurial-scm.org/D1096
__name__ is unicode, but we need bytes. For now, we'll make the
(mostly-safe) assumption that template filter names will be ascii.
Differential Revision: https://phab.mercurial-scm.org/D1137
Stops us from choking the templater on Python 3. With this patch
applied, much of hgweb works correctly in Python 3. The notable
exception is the graph page, which chokes because it gets node IDs as
str instead of bytes.
Differential Revision: https://phab.mercurial-scm.org/D1135
experimental.updatecheck was renamed into commands.update.check, use the
config system to provides the fallback on the old config name instead of
adding more code.
Differential Revision: https://phab.mercurial-scm.org/D1117
I may be a weird person for liking this style, but our C style is
historically nominally the Linux Kernel style, and when you configure
clang-format to be kernel-ish, this is what you get. If we want to
change it, we can do so by tweaking the formatter rules in the future.
Differential Revision: https://phab.mercurial-scm.org/D1132
We're moving towards a clang-format world, and clang-format is able to
wrap argument lists with spaces reliably, while still enforcing tabs
globally. Let's let clang-format do its job, and not do as much
C-style enforcement with regular expressions.
Differential Revision: https://phab.mercurial-scm.org/D1130
Depends on D932.
Call the new _onfilemergefailure function when a merge tool reports failure
via a return code.
Differential Revision: https://phab.mercurial-scm.org/D951
Depends on D931.
This patch introduces functions and a config option that will allow a user
to halt the merge if there are failures during a file merge. These functions
will be used in the next patch.
Differential Revision: https://phab.mercurial-scm.org/D932
This patch utilises the functionality added in previous patches and adds a flag
to amend command in hgext/amend to add a note to the amend. Since the note is
stored in the obsmarker metadata, this will only be useful when obsmarker
creation is enabled, otherwise this is no-op.
Not adding releasenotes part as we yet don't have a functionality in core to
show the note.
Differential Revision: https://phab.mercurial-scm.org/D1095
`commit --amend` and amend command in core and extensions rely on
cmdutil.amend() for amending a commit. So the logic to add a note to amend must
reside here. This patch assumes that note will be passed in opts dictionary to
the function and it will be passed to cleanupnodes and then createmarkers to
store the note in the obsmarker metadata.
After this patch, note can be stored on an amend changeset by passing notes as a
part of opts to cmdutil.amend().
Differential Revision: https://phab.mercurial-scm.org/D1094
This patch adds a metadata argument to cleanupnodes() which will be dict and can
be passed to obsmarker.createmarkers() and can be stored on the obsmarker.
In cases when obsolescence is not enabled, the metadata argument is useless.
This is a step towards storing a note in amend.
Differential Revision: https://phab.mercurial-scm.org/D1093
D946 fixed a bunch of tests which had the same root cause. Please see
that for details. This seems to be one of the newer tests which fails because
of the same reason.
Test Plan:
Ran the test 'test-hgweb-annotate-whitespace.t' with and without the
'--chg' option.
Differential Revision: https://phab.mercurial-scm.org/D1124
D911 tried to make this test compatible with chg but instead resulted
in the test being flaky for chg. For now, disabling this test for chg because
it seems difficult to fix the test. This will allow for the continuous build
setup for chg.
Test Plan:
Ran the test 'test-pager.t' with and without the '--chg' option.
Differential Revision: https://phab.mercurial-scm.org/D1128
This test fails when run with chg because the error message starts
with "ProgrammingError" instead of "mercurial.error.ProgrammingError".
Therefore, globing the "mercurial.error." to ensure that the test is compatible
with chg.
Test Plan:
Ran the test 'test-obsolete-bounds-checking.t' with and without the
'--chg' option.
Differential Revision: https://phab.mercurial-scm.org/D1127
The test is broken when run with chg because it prints a different
error message when chg is running. This commit fixes the test by special casing
for chg.
Test Plan:
Ran the test 'test-dispatch.t' with and without '--chg' option.
Differential Revision: https://phab.mercurial-scm.org/D1126
D942 removed the experimental config 'histeditng'. This is a leftover
which should have been removed in that commit. Therefore, this commit completes
the cleanup.
Test Plan:
Ran all the tests.
Differential Revision: https://phab.mercurial-scm.org/D1123
With in-memory merge, copy information needs to be stored in-memory, not in the
dirstate.
To make this transition easy, move the existing dirstate-based approach to
workingfilectx; that way, other implementations can choose to store it
somewhere else.
Differential Revision: https://phab.mercurial-scm.org/D1106
With in-memory merge, backup files might be overlayworkingfilectxs stored
in memory. But they could also be real files if the user's backup directory is
outside the working dir.
Rather than have two code paths everywhere, let's use arbitraryfilectx so they
can be consistent.
Differential Revision: https://phab.mercurial-scm.org/D1057
This patch adds support for storing the type of command which is going to run in
the func object. For this it does the following:
1) Add three possible values as attributes to the registrar.command class
2) Add a new argument to registrar.command._doregister function
3) Add a new attribute cmdtype to the func object
The type of command will be helpful in deciding what level of access on hidden
commits it can has.
Differential Revision: https://phab.mercurial-scm.org/D736
The function document says that it returns true when the fragment can be merged,
but if you see the function just above it which is similar(), it writes already
exists thing if return value from similaritycheck() is False which is just
opposite of the doc. This patch fixes that.
Differential Revision: https://phab.mercurial-scm.org/D1119
