Summary:
Historically treeonly clients were ignoring flat manifests sent in
bundles, but with a recent change they will now try to recreate those manifests
when they receive such a bundle (so we don't lose any data when a user does 'hg
unbundle' on a flat-only bundle). This means we need to stop sending flat
manifests from the server to treeonly clients.
Differential Revision: D7083028
fbshipit-source-id: e4580b00a8be96fbef0ee624529c58f41cfa2752
Summary:
Previously we were only wrapping the changegroup packers for the
clients. In a future diff we want to use the shallow changegroup packers to
govern when to send trees from the server, so we need them enabled for the
server.
It turns out they were mostly enabled for the server already. While we weren't
replacing the classes in changegroup._packermap (which is what they get
instantiated from), we were replacing them via the interposeclass decorator.
This meant that the server would construct a cg3packer, but it would have a
shallowcg1packer in the class hierarchy, so most of the code was running
already. So this should be a pretty low risk change. In theory.
Differential Revision: D7083042
fbshipit-source-id: 5ce44a9ceda4d7d4bd126f52a01e45e6e1e7de40
Summary:
Eventually all the clients using the tree manifest will operate in
treeonly mode. In treeonly mode, we only read from tree manifests and
therefore, manifest related operations would fail for commits which only have
flat manifest. Example of such commits are old draft commits which were created
before the existence of tree manifest. One way to resolve this is to
automatically convert any flat manifests we come across to tree manifests. This
commit achieves that same.
Differential Revision: D7083033
fbshipit-source-id: 092fc7852ffc6d1b4130b5a1fc8d9e124cef4fcb
Summary:
We were already hacking the ui object onto the manifestlog via the
treemanifest extension, but it didn't cover all cases. Let's just put it on the
manifestlog via the constructor and get rid of the hack. An upcoming change
required this
Reviewed By: phillco
Differential Revision: D7083032
fbshipit-source-id: 4c577cb80193a9c4799853d75a71c26719348e8c
Summary:
Previously we added the mutable packs to the union stores directly when
the mutable packs were first created. This meant we didn't have fine grained
control over what order the mutable pack was in the store. Since we want the
mutable packs to be before the remote store and before the upcoming ondemand
store, we need to insert it into the list at store initialization time.
We can't insert the mutable packs themselves, since they are opened and closed
all the time, but we can insert a proxy class that knows how to find the current
mutable pack on the manifestlog.
Differential Revision: D7083045
fbshipit-source-id: c08a877783c6bb6b95beac4e40544880a6bd3a8f
Summary:
In some cases the generating store could result in infinite recursion
if the generate function didn't actually produce the desired value. Let's add a
context manager to guard against this.
Reviewed By: mjpieters
Differential Revision: D7083030
fbshipit-source-id: 5e0037addbf2ba9fa9d4e222291cc4543da5c659
Summary:
Adds the mutable stores to the union store when they are created. This
will allow reads to access data that has been written but not finalized. This
will be important in later patches for converting a series of trees as part of a
single transaction.
Differential Revision: D7083031
fbshipit-source-id: 25ddbb1dbd29ad6b4164733b6d893b9c69d9d65e
Summary:
This makes the mutable history pack implement the history store read
api so we can add it to the union store and read the contents of things that
have been written but not yet committed.
The mutablehistorypack fileentries variable has been changed to contain a dict
instead of a list so we can access it quickly during reads. The list is from a
legacy requirement where we used to maintain the order that the writer wrote in.
We no longer do that (instead we topologically sort what they've given us), so
switching from a list to a dict should be fine.
Differential Revision: D7083036
fbshipit-source-id: ae511db60ab6432059714a2271c175dc9683b8e1
Summary:
Now that _writeclientmanifest is basically just calling
manifestlog.add, let's get rid of it.
Differential Revision: D7083029
fbshipit-source-id: eee18cefd5a6ae3d95bba58b419364fc9fdb15b3
Summary:
As part of moving the manifest mutable pack logic to be used optionally
without transactions, let's move the lifetime logic
out to the repo.transaction() function instead of being part of the primary manifest
write logic.
Differential Revision: D7083035
fbshipit-source-id: 9947d78db61a41896cc8bdfaaa20504ebb03a125
Summary:
Previously the mutable packs were kept on the transaction and had a
lifetime that corresponded with it. In a future patch we want to enable mutable
packs that span for longer than the lifetime of the transaction, so let's move
the mutable pack maintenance on the manifestlog. For now the lifetime is still
maintained by the transaction, but a future diff will change that as well (and
will get rid of _writeclientmanifest entirely).
Differential Revision: D7083034
fbshipit-source-id: 3735eadfc18e5dd1015bfb82dbf5b9e9e6965cdf
Summary:
As part of a series of diffs that will remove the need for addmemtree,
let's remove it from the _writeclientmanifest function so we can replace
_writeclientmanifest with a cleaner interface that doesn't call addmemtree.
Reviewed By: ryanmce
Differential Revision: D7083037
fbshipit-source-id: 51885ec547df5aa21e66afe36eb1f3224c3eae66
Summary:
We now have a unified place for writing trees to packs, so let's move
the fastmanifest code to use it.
Reviewed By: ryanmce
Differential Revision: D7083043
fbshipit-source-id: f5fc312b7614906b917fc7ca10866705fbd47aac
Summary:
A future diff will be removing the fastmanifest tree write helper. To
simplify that transition, let's move all the fastmanifest specific logic out of
the fastmanifest helper function.
Reviewed By: ryanmce
Differential Revision: D7083054
fbshipit-source-id: bf023efb857af2511b4ed7ae7ef069ee15575f08
Summary:
A future diff will move fastmanifest to use the common
_writeclientmanifest logic. Since the logic is subtly different, let's do it in
stages by first moving the existing logic to its own function (this diff), then
refactoring out the differences, then moving to the common _writeclientmanifest.
Reviewed By: ryanmce
Differential Revision: D7083044
fbshipit-source-id: 55d14d1fb0d95b1ba6c130b58deb21cbc97501fc
Summary:
There are a few tweaks necessary to keep the tests passing in upcoming
diffs. Most of these are deleted by the end of the series, but having them now
makes the diffs cleaner.
Reviewed By: ryanmce
Differential Revision: D7083040
fbshipit-source-id: 70a09ba1dd573f9cd5c24080f2811db21cc54938
Summary:
In a future patch we're going to make the manifestlog control it's own
writes and the lifetime of its write objects. We are currently hacking up a
normal manifest to attach a treemanifest to it, which makes it awkward for it to
maintain the lifetimes of both the normal manifest and the treemanifest. Let's
move the existing logic into a class of its own so we can attach more logic in
the future.
Reviewed By: ryanmce
Differential Revision: D7083039
fbshipit-source-id: 7646b787c36af76650e77f8e6192cd266093c8ea
Summary:
Adds addstore and removestore to the union history store, just like
we've already done for the union data store.
Reviewed By: ryanmce
Differential Revision: D7083055
fbshipit-source-id: 49f1a4156376d0cf5d6191c4d30ec923ddb2ec14
Summary:
In a future diff we'll need the ability to modify the union store on
the fly, so let's add addstore and removestore apis.
Reviewed By: ryanmce
Differential Revision: D7051102
fbshipit-source-id: 901a50720bfdf4e5c59714d092830e65edccdfce
Summary: The linters complain about this now, so let's format everything.
Reviewed By: ryanmce
Differential Revision: D7057989
fbshipit-source-id: 987ad0dcaa2f4e8fb74b3aa19c496f378765a533
Summary:
D6867913 refactored the server side flat manifest to tree manifest
conversion code path. This commit builds on that and introduces support for the
same on the client side.
Reviewed By: singhsrb
Differential Revision: D6867928
fbshipit-source-id: 7198d3a5ff9834482c0e7423d3ab501423d72a40
Summary:
D6867913 did a bunch of refactoring which can be extended for the write
manifest wrapper. This commit achieves the same.
Reviewed By: singhsrb
Differential Revision: D6867921
fbshipit-source-id: c86cf1d54ecd3503127d91acf7a114d4d99f50ff
Summary:
This commit is essentially a refactor to further break down the
process of converting flat manifest to tree manifest. This enables further code
refactoring and reusability in later commits.
Reviewed By: ryanmce
Differential Revision: D6867913
fbshipit-source-id: 86b2ec41932eef6297169f0667190e03caab35a1
Summary:
Introducing class generatingdatastore to represent all stores like
remotetreedatastore which generate the trees when they are not found in the
shared store, add them to the shared store, and thereafter, repeat the original
operation on the shared store expecting it to succeed.
Reviewed By: ryanmce
Differential Revision: D6867898
fbshipit-source-id: 59af9d4833e402b36c35b6247d319888d19bef66
Summary:
The plan is to eventually subclass remotetreedatastore and this
refactor sets us up nicely for that.
Reviewed By: ryanmce
Differential Revision: D6867885
fbshipit-source-id: 2eb2ad0068183b8f972e1a187a65854d331e09d9
Summary:
writepending needs to return False so the transaction mechanics know there is no
further work to be done here. This was just something caught during development.
Reviewed By: ryanmce
Differential Revision: D6867879
fbshipit-source-id: 73d49b06c5379f9a3388d42fbb454b5eba534a20
Summary:
If there is already a committed flat manifest node, then we need to
use that while writing the corresponding client tree manifest so that the tree
manifest is referable from the flat hash.
Reviewed By: ryanmce
Differential Revision: D6867873
fbshipit-source-id: e86a9aad4fa113dfc3fecc0fbb753dee77f26f24
Summary:
The logic for writing client tree manifests can be reused and thus, it
makes sense to move this out into a separate method.
Reviewed By: ryanmce
Differential Revision: D6867863
fbshipit-source-id: 5d24f181dcf4fdf8752d96c12c550c447898ce61
Summary:
A future patch will need the ability to convert a linknode to a linkrev and vice
versa without having access to the changelog (when converting a flat manifest
into a treemanifest we need to get the linknode from the flat manifest, and all
we're given is a linkrev). Let's stick the changelog on the manifestlog. Since
they are generally created together and have the same lifetime, this seems safe.
Reviewed By: ryanmce
Differential Revision: D7034091
fbshipit-source-id: df6915f894c6ef975ffd214c8e229f1085141fbc
Summary:
The union content store
- iterates through all the stores it has until the current store has the
content.
- Or, it fails eventually if none of the stores have the content.
It does so by relying on the current store throwing a KeyError if it doesn't
have the content.
`remotetreedatastore` was throwing the MissingNodesError which means any
remaining stores after it would not even get a chance to look for the content.
This commit addresses the same.
Reviewed By: ryanmce
Differential Revision: D6867854
fbshipit-source-id: 784df195efcbe16f2e716968f3d93159afff6206
Summary:
The root issue is described in the new ``workingflags()`` function -- ``workingfilectx.flags()`` ought to read from the working copy, but instead reads from the working copy's p1.
Rather than force a big rewrite to adapt all the old code (which might be a waste if we end up rewriting the context classes), let's add a new function with the behavior we want, and callers can detect for it and call it.
simplemerge is the only callsite that needs this behavior, AFAICT.
Previous attempt: D6694292
Reviewed By: singhsrb
Differential Revision: D7083239
fbshipit-source-id: 6f30b877958d40106203e088fe724ab491b541b9
Summary:
Remove the test for the `search` attribute on the passed-in regexp in
`hghave.matchoutput`. It's not necessary, and causes new check-code errors.
Reviewed By: quark-zju
Differential Revision: D7098248
fbshipit-source-id: b5f18c0db3cfbb37c9f7e23e2cdfdef9cedd3f49
Summary:
`hg purge --dirs` is slow because it asks for all the directories in the repo,
which disables the fsmonitor speed improvements to dirstate.walk.
To make purge faster, separately query watchman for all the dirs in the repo
(it can answer this fairly quickly).
Reviewed By: mjpieters
Differential Revision: D7067811
fbshipit-source-id: 18e76c685bd630862d12e7e59c2817a8f45ed073
Summary:
Some of our internal hg builds include the Eden extension now. This was
causing the test-help.t test to fail since it included help output for the Eden
extension, but the test code did not expect this.
We unfortunately cannot update the test output to always expect help output for
Eden since the Eden extension is only included in buck-based builds.
Reviewed By: quark-zju, farnz
Differential Revision: D7063937
fbshipit-source-id: e503ddc6889e546b5333a8d9e3555097d689e24c
Summary:
Update run-tests.py to cache the results of hghave checks. Some of the
linematch code can end up calling _hghave() hundreds of times in a row with the
same check.
This is particularly likely to happen on test failures, where a line with an
hghave check does not match the expected output. In this case the same hghave
check will be re-run on each subsequent line of test output.
Reviewed By: quark-zju, farnz
Differential Revision: D7077677
fbshipit-source-id: 768a11df78924b75cde4c8b48c801b79194f7969
Summary:
Add a new `--only-files-in-revs` option to `hg diff`. This filters the files
that are considered down to the set of files that are touched in either of the
two revisions.
Reviewed By: ryanmce
Differential Revision: D7070102
fbshipit-source-id: b9140cd3a212af9554ef5b76785210c1dbba8ee0
Summary:
metaedit when metaediting a commit with obsolete & visible children did
autorebase all of them causing a divergence (which broke the restack)
Reviewed By: ryanmce
Differential Revision: D7067121
fbshipit-source-id: 679bc7acecde1cd648adcdddc9c8ac3ecc101208
Summary:
`hg show REV FILE` would hang indefinitely, while `hg log -p FILE -r REV` works
fine. The reason is that fbshow extensions calls log command from commands.py
directly. But remotefilelog extension wraps log command and adds special
options to make it faster.
Let's call the wrapped version of log command
Differential Revision: D7066869
fbshipit-source-id: 3bda4b3b1a1fe9503eb05355816b28ba924048ff
Summary: It didn't properly turn off IMM after D6817683, but ran the rebase with IMM again.
Reviewed By: singhsrb
Differential Revision: D7072951
fbshipit-source-id: 9f9386fbd5748ff002de2c60132d5d5708380714
Summary:
When compiling with optimization enabled gcc complains that result is not
immediately initialized when created inside a constexpr function.
Differential Revision: D7065250
fbshipit-source-id: 5a829e775ce482c8a5ec9d1cfe279005ff11bb7e
Summary: Including bookmarks in the crdump output
Reviewed By: sfbahr
Differential Revision: D7063784
fbshipit-source-id: 08d38d8a73a8448b3a184bfc3511cdaec01771fb
Summary:
Exposed by UBSAN:
```lang=bash
scm/hg/mercurial/cext/pathencode.c:61:40: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
#0 0x7f60c372b2e7 in inset scm/hg/mercurial/cext/pathencode.c:61
#1 0x7f60c373022c in _encode scm/hg/mercurial/cext/pathencode.c:424
#2 0x7f60c372a605 in basicencode scm/hg/mercurial/cext/pathencode.c:480
#3 0x7f60c3729f90 in pathencode scm/hg/mercurial/cext/pathencode.c:744
```
Use unsinged 1 in the shift operation to fix the UB
Reviewed By: wez
Differential Revision: D7073320
fbshipit-source-id: 8e714c41e94474c4c62b3b6730df6fe99f9c0391
Summary:
We don't really support files larger than 2G with files larger than
4G remotefilelog crashes badly.
Reviewed By: markbt
Differential Revision: D7066855
fbshipit-source-id: 40cdebbe703a7b3f13ce84174bf6f96565e8c3b7
Summary:
Turns out this function can read from the working copy because it calls `match`. `experimental.merge.checkpathconflicts` does what this function does without that problem and without a perf hit. So, nuke it!
Also add a test.
Previous version: D7070540
Reviewed By: singhsrb
Differential Revision: D7072247
fbshipit-source-id: a217ffd575daf8271411a77c422e1dcdd387dfbb
Summary:
If the user specifies a revision using `-r`, along with
`--since-last-arc-diff`, then show the differences for that revision, rather
than the working copy parent.
Differential Revision: D7068359
fbshipit-source-id: feffadeb45eed4e1d8bb9d8fc7040932ada31736
Summary:
The fbhistedit `exec` verb attempts to create an obsmarker if the working copy
parent is changed as a result of the command execution.
This isn't always valid to do: the command could have created a new commit
entirely, and the old working copy parent could be public, and thus not
obsoletable.
It's also not necessary. If the command that ran during the exec did anything
that obsoleted commits (e.g. amend), then it should have created its own
obsmarker.
Differential Revision: D7066784
fbshipit-source-id: 326396828a06936c88154cfec6705f7834527a5f
Summary:
Inserting a commit after a public commit causes histedit to fail
when it tries to write out the obsmarkers.
Reviewed By: ryanmce
Differential Revision: D6820504
fbshipit-source-id: 1f73bde65eb87485b0712d6a365b846fd00ad48c
