In order to fix the missing lfs store after an upgrade, I attempted to walk the
store vfs to hardlink to the upgraded repo's store. But the custom join()
clashes with the default walk() implementation. First, 'path=None' blew up in
the regex matcher, because it wanted a string. But even if that is fixed, the
join to walk the root of the vfs wouldn't match the required xx/xx...xx pattern.
The first cut of this was a copy/paste/tweak of the base implementation, but
this version of walk() hides the internal directories, and treats the vfs as a
flat store. I think this makes sense because most vfs methods call join() on
input paths, which wants the simple oid format. It also relieves the caller
from having to deal with bogus files/directories in the store.
Keys of keyword arguments must be str(unicode) on Python 3. The transformer
which we use on Python 3, appends b'' in front of each string literal, so this
may lead in KeyError or None return even when the key is present by we are using
bytes value and it's stored in unicodes. This patch and all the similar patches
handle this by either converting the keys of kwargs to bytes using
'pycompat.byteskwargs()' or adding r'' so that the transformer won't append
b''.
This next 23 patches follows the above mentioned way to handle keyword
arguments.
Differential Revision: https://phab.mercurial-scm.org/D1624
This patch renames remotenames.py to logexchange.py, test-remotenames.t to
test-logexchange.t. Also this patch renames the directory in which the data is
stored from remotenames to logexchange. After this patch, data about bookmarks
and branches from a server we pull is stored in
`.hg/logexchange/(bookmarks|branches)` files.
Thanks to smf for the suggestion.
Differential Revision: https://phab.mercurial-scm.org/D1607
The extensions wrap the necessary function to ensure the 'lfs' requirements
won't be dropped.
It is now possible to run `hg debugupgraderepo` on a repository with lfs.
We add a new mode for delta recomputation, when selected, each full text will
go through the full "addrevision" mechanism again. This is slower than
"redeltaall" but this gives the opportunity for extensions to trigger special
logic. For example, the lfs extensions can decide to promote some revision to
lfs storage during the upgrade.
By using the standard path to create a repository we fill some hole in the
current initialization process. The one who triggered this changeset was the
lack of extensions initialization.
The `repo.baseui` contains all the configuration but the one specific to the
repository (so it can be used when dealing with local peer and sub-
repository). However, we need the repository config to be taken into account
when doing the upgrade. Otherwise, the upgrade related config that exists in
the repository config won't be taken into account when performing the update.
A buggy and surprising behavior.
We had to work around protection set around `repo.ui.copy` since we are an
uncommon case.
The upgrade process ignores the config within the repository. The next
changeset fixes it, but we introduce this test before to show it actually
tests our target.
The new label highlight areas where the repo format differs from current
config or default. This should help people spot area where a repository
mismatch with the expected state.
The command displays basic data about all format variants registered for repo
upgrades. This gives a quick way to peek into a repository format.
The 'fm.write()' calls are very independent because more data will be added in
later changeset. Having more separate call make the later patch clearer.
The new naming is more descriptive of a "state" while the older one was more
about "action". I'm looking into command exposing more of data about the state
of the repository so "state" oriented work better there.
The key has not been made public anywhere outside the debug area so it is fine
to update it.
As described in the comment, rebasing the working copy parent with in-memory
merge, and then updating to the new commit, isn't much faster because of the
extra overhead of uppdating. Best to leave it off in that case.
This commit makes deploying in-memory merge via an extension easier, because
you can just set `inmemory=True` based on some config or probability, and this
will turn off the cases where it's not desired.
Differential Revision: https://phab.mercurial-scm.org/D1616
If `experimental.remotenames` is set to True, we store the remotenames in case
of `hg pull`. This patch adds that support to clone command also.
Differential Revision: https://phab.mercurial-scm.org/D1601
Other revsets like secret(), draft(), _nonpublic() are using
phasescache.getrevset already. The latter is more efficient after D1606.
So let's migrate the public() revset function too.
Tested using:
$ hg debugshell --hidden --cwd hg-committed`
In [1]: %timeit len(repo.revs('public()'))
* Before D1606: 10 loops, best of 3: 22.5 ms per loop
* Before this change, after D1606: 10 loops, best of 3: 28.6 ms per loop
* After this change: 10 loops, best of 3: 20.2 ms per loop
Therefore `public()` revset becomes even slightly faster after the data
structure change by D1606. A similar performance win could also be observed
on a large repo.
A side effect is `phasecache.getrevset` needs to take a `subset` parameter.
That was added with a default value so it won't cause BC issues.
Differential Revision: https://phab.mercurial-scm.org/D1620
Since highlight is only relevant for servers, it seems worthwhile to
just trigger this eagerly, which avoids really weird traceback
problems caused by demandimport messing with some of the lexer plugins.
Differential Revision: https://phab.mercurial-scm.org/D1619
This fixes problems noticeable when rebasing several commits into one
destination commit using ``--collapse``. The manifest cache needs to be cleared
each time.
Differential Revision: https://phab.mercurial-scm.org/D1244
Alas, presence of a key in the cache isn't sufficient evidence that the file
is actually dirty.
Differential Revision: https://phab.mercurial-scm.org/D1243
Alas, part of Mercurial's conflict detection (for file<->folder conflicts,
for example) depends on the filesystem. We don't have the filesystem with IMM,
so we have to run these checks ourselves.
Differential Revision: https://phab.mercurial-scm.org/D1241
We no longer inherit ``workingctx``'s version, but we also don't need to do
anything anymore.
Differential Revision: https://phab.mercurial-scm.org/D1239
