Summary:
Move the rust libraries and extensions to their new locations, and integrate
them with the hg-crew setup.py.
Test Plan: Run `python setup.py build` and verify rust extensions are built.
Reviewers: durham, #mercurial
Reviewed By: durham
Subscribers: fried, jsgf, mitrandir
Differential Revision: https://phabricator.intern.facebook.com/D6677251
Tasks: T24908724
Signature: 6677251:1515450235:920faf40babbce9b09e3283ff9ca328d1c5c51e6
Summary:
Move hgsql into the hgext directory, and the tests to tests/test-hgsql-*.
Update the tests to refer to the new places for things.
Test Plan: Run the hgsql tests and make sure they pass.
Reviewers: #sourcecontrol
Differential Revision: https://phabricator.intern.facebook.com/D6660499
Tasks: T24908724
In preparation for adding more conditions that will disable IMM, let's make
this framework more extensible and log the reason IMM wasn't used.
The `whynotimm` variable name matches the `why_not_eden` name in
`hg/eden/__init__.py`.
Differential Revision: https://phab.mercurial-scm.org/D1785
Some callers to rebase.rebase(), like `_moverelative` in `fbamend/movement.py`,
wrap the entire rebase call in a transaction. This raises havoc when IMM tries
to retry the rebase when it hits merge conflicts, because the abort will fail
the whole transaction, not the subset. It also fails at the end, losing any
conflict resolution, as @sid0 noticed.
The right long-term fix that @quark and I have discussed is to change the
restarting logic such that it doesn't abort at all, but simply switches between
IMM and non-IMM fluidly for each commit, which has other nice properties. In
the meantime this will do for now.
Differential Revision: https://phab.mercurial-scm.org/D1782
We need hash-preserving unamend. Therefore remove the core version.
(grafted from 86e055fbb0c974e041dbd72cd95df6e3b37a0f6b)
(grafted from 129f15c3acd81d4390212430ea6b500412bc74ab)
(grafted from fbb42eb996d5bcddac4ba4e86a915a3bc62b3e16)
02c30db0443d (lfs: add a repo requirement for this extension once an lfs
file is committed) introduced a regression that prevents committing file
deletion. This patch fixes that.
Differential Revision: https://phab.mercurial-scm.org/D1717
This will allow developers to test against various server implementations. I
didn't put it under [devel] because it's possible that some user needs to use it
in the field.
As we were trying to transition off of the non production lfs-test-server for
further experimenting, one of the problems we ran into was interoperability. A
coworker setup gitbucket[1] to act as the blob server, tested with git, and
passed it off to me. But push failed with a message saying "abort: LFS server
returns invalid JSON:", and then proceeded to dump a huge HTML page to the
screen. It turns out that it is assuming that git is the only thing that wants
to do a blob transfer, and everything else is a web browser wanting HTML.
It's only a single data point, but I suspect other things may be doing this too.
RFC7231 gives an example [2] of listing multiple products in decreasing order of
significance. Since the standard provides for this, and since it works with the
one problematic server I found, I'm just enabling this by default for a better
UX.
There's nothing significant about the version of git chosen, other than it is
the current version.
[1] https://github.com/gitbucket/gitbucket/
[2] https://tools.ietf.org/html/rfc7231#page-46
I don't see why unamend should be disallowed when allowunstable is
set. By switching to rewriteutil.precheck() we fix that and get more
consistent error messages (and some additional ones).
Differential Revision: https://phab.mercurial-scm.org/D1682
This significantly speeds up lfs prefetch. With fast network we are
seeing ~50% improvement of overall prefetch times
Because of worker's API in posix we do lose finegrained progress update and only
see progress when a file finished downloading.
Test Plan:
Run tests:
./run-tests.py -l test-lfs*
....
# Ran 4 tests, 0 skipped, 0 failed.
Run commands resulting in lfs prefetch e.g. hg sparse --enable-profile
Differential Revision: https://phab.mercurial-scm.org/D1568
The branch information was properly preserved in the changeset, but the
"active" branch of the working copy could be lost (the branch of the base
being used).
Histedit used to behave properly in this regard but the case was not tested
and regressed 4 years ago in c038baa4b6f0.
This effectively conditionalizes 7ac081713920. Some Linux distributions (like
CentOS 7) use really old versions, and the change referenced was causing
exceptions to be thrown.
Even though the deprecation warning says 'since 2.5.0', it wasn't marked as such
in 2.5.1, but is by 2.6.0. This was tested with 2.4.2 and 2.6.0 with
PYTHONWARNINGS=::DeprecationWarning, and both paths were exercized.
Previously, the largefile for a dropped standin would be deleted here, and then
restored from the cache. This had the effect of clobbering uncommitted changes
if a revert caused the file to be forgotten, which is not what happens with a
normal file. Now the removal and update is skipped for dropped largefiles, and
the corresponding standin is deleted from disk.
This was noticed when working on issue5738 because the forgotten standin files
were left behind, and that changes the behavior of the next rename to that
directory. My first attempt was to cleanup the standins before calling this.
That failed, because this function deletes the largefile if the corresponding
standin is missing.
This function is called by the revert command, merge (and therefore update), and
patch, via the scmutil.marktouched() override. So it should be pretty narrow in
scope.
I didn't mark issue5738 as fixed because the move related issues can still
happen if the main tree and the .hglf subtree get out of sync somehow. I don't
see an easy fix for that, but that should be an edge case. If whoever queues
this thinks it is good enough to close out the bug and can cram it into the
summary, go for it.
The `hg lfconvert --to-normal` command uses the convert extension internally to
work its magic, but that produced devel-warn messages if the convert extension
wasn't loaded by the user. The test in 658e7a6d93e0 (modified here) wasn't
showing the warnings because the convert extension was loaded via $HGRCPATH.
Most of the config options default to None/False, but 'hg.usebranchnames' and
'hg.tagsbranch' are supposed to default to True and 'default' respectively.
The first iteration of this was to ui.setconfig() inside lfconvert, to force the
convert extension to load. But there really is no precedent for doing this, and
check-config complained that 'extensions.convert' isn't documented. Yuya
suggested this alternative.
This partially backs out 448e09d8859d.
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.
If the legacy pager extension is enabled, a pager is started through repo.ui
at dispatch._runcommand(). After that, mqcommand() creates a qrepo with a
fresh repo.baseui, at which point pager information was lost and another pager
would be spawned by the modern pager interface.
This is a minimal workaround for the problem.
5c25fe7fb1e broke something in the hgsubversion test path, causing it raise an
abort (Abort: nothing to merge) during a perfectly good rebase. I tracked it
down to this change. It's probably not hgsubversion related.
I suspect that using the same `wctx` from before the initial update causes
problems with the wctx's cached manifest property. I noticed we also sometimes
stick random gunk on the wctx object in other places (like in `copies.py`) so
it's probably best to reset it for now.
The line I added before was actually useless since we don't pass wctx to the
initial `merge.update`, so it defaults to `repo[None]`. So I just removed it.
Differential Revision: https://phab.mercurial-scm.org/D1679
committablefilectx has three subclasses: workingfilectx, memfilectx,
and overlayfilectx. committablefilectx takes an optional (change) ctx
instance to its constructor. If it's provided, it's set on the
instance as self._changectx. If not, that property is supposed to be
defined by the class. However, only workingfilectx does that. The
other two will have the property undefined if it's not passed in the
constructor. That seems bad to me. This patch makes the changectx
argument to the memfilectx constructor mandatory because that fixes
the failure I ran into. It seems like we should also fix the
overlayfilectx case.
Differential Revision: https://phab.mercurial-scm.org/D1658
This is just a very simple start, but verifies some of the basic cases of an
in-memory rebase.
Differential Revision: https://phab.mercurial-scm.org/D1652
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
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.
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
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
