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
Summary:
Let's try to be consistent and print relative path names during merge. Note
that it changes test output for mq and subrepos, but we don't use these
features often, so it should be fine.
Differential Revision: D7067050
fbshipit-source-id: 3aba66e67657a1b1b30fcf239c03abd605eb5d9a
Summary:
Delete hgext/extlib/cstore/bitmanipulation.h, and just use the existing
mercurial/bitmanipulation.h header file instead.
It looks like there are quite a few other copy-and-pasted files between these
directories too, which should probably still be cleaned up.
Reviewed By: quark-zju
Differential Revision: D7008478
fbshipit-source-id: 1fdc779b470242d3083a3948dace3951922e836c
Summary:
memcpy() must not be called with a null source pointer, even when the length
argument is 0:
https://www.imperialviolet.org/2016/06/26/nonnull.html
The current behavior causes `hg commit` to crash when compiled with UBSAN
enabled.
Reviewed By: chadaustin, wez
Differential Revision: D7055450
fbshipit-source-id: 40afb40cb346d608fa0e59012bc329b5702ec651
Summary:
`hg debugpathcomplete` is another example where the current implementation
iterates the whole dirstate looking for information that's in one directory.
With treedirstate, this can be made faster by using the tree structure.
Differential Revision: D7024784
fbshipit-source-id: 3c0b403887e85157b7eb2752abce5a0805e6ed1c
Summary: Apply rustfmt to tree.rs so that future changes can use it.
Reviewed By: ryanmce
Differential Revision: D7024785
fbshipit-source-id: 2a21a1fe18bcb018a38e26fe851d50fe633e2238
Summary:
"hg" only ignored ENOENT errors when including files (so it didn't abort when an included file didn't exist). But it aborted on every other error (e.g EPERM).
This diff makes it ignore any IOError and just print a warning.
Reviewed By: quark-zju
Differential Revision: D7029320
fbshipit-source-id: b1b8137cd575fc89fb5967e8d18fe82ab84a8f85
Summary:
Running `hg log --traceback --template '{file_copies}' -r XXXX` on a file with long history is slow for 2 reasons
- p4 fast importer preserves full history for deleted and re-added files
- p4 fast importer records the wrong parent of a file
This diff tries to fix these two issues.
In mercurial, if a file is added, deleted, and then added back, it should start a new file history when the file is added again.
For example,
commits commit1 commit2 commit3
actions add a.txt delete a.txt add a.txt
timeline ------------X------------X------------------------X------------
`hg debugindex a.txt` at commit3 shows a.txt as a new file without previous history
rev offset length delta linkrev nodeid p1 p2
0 0 3 -1 0 b789fdd96dc2 000000000000 000000000000
However, this is different in p4. `p4 filelog test.txt` gives you
//depot/Software/Apps/Main/Native/.castle/test.txt
... #3 change 523261 add on 2018/01/23 by zhihuih@devbig415 (text) 'test:add-again-same-file'
... #2 change 523254 delete on 2018/01/23 by zhihuih@devbig415 (text) 'testfile:delete'
... #1 change 523253 add on 2018/01/23 by zhihuih@devbig415 (text) 'testfile:add'
Currently, p4 fast importer preserves history the same way as p4, and this causes slowness (even timeout) in hg when it runs `hg log --traceback --template '{file_copies}' -r XXXX` on a revision that contains files with long history in p4 (mostly contributed by automation). To mitigate this, we want the p4 fast importer to behave the same way as hg, and starts a new history for a file that's added again.
Currently, p4 fast importer takes the tip of a filelog and treats that as the parent of the newly written entry diffusion/FBS/browse/master/fbcode/scm/hg/hgext/p4fastimport/importer.py;19ad9b05f50e3ff0265cdc7b4b45174dcf820343$468-469. This can be wrong when there are revisions from branches.
For example, if I edit file a in master in CL1, 2, 4, and I branch at CL3, and edit the file in branch in CL5, the current importer implementation will take filenode at CL4 as the parent of CL3
(CL1,2,3,4,5 corresponds to rev0,1,3,2,4)
{F120393661}
However, the correct behavior is to take filenode at CL2 as the parent of CL3
(CL1,2,3,4,5 corresponds to rev0,1,3,2,4)
{F120393662}
(This is also the example I use in `test-fb-hgext-p4fastimport-import-branch-filelogorder.t`, so if the description here looks confusing, please refer to the test)
Reviewed By: dsp
Differential Revision: D6962019
fbshipit-source-id: 24de76ae009e0d6f976d247087fe4702c99e0f82
Summary:
Update the treemanifest extension to also add a 'gettreepack()' function to
localpeer, and add the 'gettreepack' capability to localpeer if the repository
supports acting as a treemanifest server.
Also update the _addmanifestgroup() wrapper to only forbid it from being called
in a treemanifest server repository. When pulling from a local treemanifest
server repository this function may need to be invoked in the client
repository.
Reviewed By: DurhamG
Differential Revision: D6980931
fbshipit-source-id: 61519c7deeaa0347650323a0002b89597e91d9cc
