- Mar 14, 2019
-
-
Pierre-Yves David authored
The manifest full text cache is tightly related to the working copy. We should use the `wcache` directory for it, instead of the `cache`. Otherwise, multiple shares would keep overwriting each other cache entry and we loose its benefit. This is also more consistent with the fact this cache file is protected by `wlock`.
-
- Mar 15, 2019
-
-
Pierre-Yves David authored
The `wlock` is taken by both `update` and `commit` type operation. This would help persisting the cache more aggressively. An explicit test is introduced. However, we can already see the effect of this change on earlier test output.
-
- Mar 14, 2019
-
-
Pierre-Yves David authored
Right now the cache is empty before this section of the test. However, we are about to improve the persistence of the cache (putting it under `wllock`, intead of `lock`). So we install the cleanup before.
-
- Mar 15, 2019
-
-
Pierre-Yves David authored
This make the code clearer and simpler to update.
-
Pierre-Yves David authored
There a no point preparing a closure if we are not going to use it.
-
- Mar 14, 2019
-
-
Pierre-Yves David authored
-
- Mar 15, 2019
-
-
Pierre-Yves David authored
Accessing value with `.get` alter the iteration order and make the output of the debug command misbehave, showing multiple entry twice. We need more than 2 entry to see the bug, so there are not test change. Later test will introduce a third entry and would fail without this fix.
-
Pierre-Yves David authored
This is more practical.
-
Gregory Szorc authored
Currently, dist.wxs contains an enumeration of .pyd and .dll files staged to dist/lib by py2exe. Having a manual list of files is error prone, as things can easily get out of sync (as the previous commit demonstrates). This is especially an issue for TortoiseHG, which ships a number of custom modules, which may pull in additional dependencies. Let's prevent this problem from manifesting by dynamically generating a .wxs file containing the .pyd and .dll files staged by py2exe. Differential Revision: https://phab.mercurial-scm.org/D6139
-
Gregory Szorc authored
For convenience. Differential Revision: https://phab.mercurial-scm.org/D6138
-
Gregory Szorc authored
dist.wxs is currently missing some .pyd and .dll files which are picked up and staged by py2exe. This means that the WiX installer is missing some Python extension modules and their dependencies which are referenced by Mercurial or a Python package distributed with it. This commit adds the missing files to the WiX installer. Differential Revision: https://phab.mercurial-scm.org/D6137
-
Gregory Szorc authored
py2exe is picking up crypt32.dll as a dependency and is including the DLL in the dist/lib directory, where it can get picked up by an installer and distributed. crypt32.dll is a core Windows DLL since Windows XP. We don't need to distribute it. Differential Revision: https://phab.mercurial-scm.org/D6136
-
- Mar 14, 2019
-
-
Gregory Szorc authored
I had ported the x86/x64 behavior difference from the Inno Setup installer files. Why things were this way, I'm not sure. The WiX configuration files are expecting to have standalone DLL files for both configurations. And the 32-bit WiX installers were broken due to missing DLLs. Let's standardize on standalone DLL files on all configurations for consistency. I /think/ this will be faster, as I /think/ py2exe binaries would have to extract the DLL to a temporary file in order to load it. But I'm not 100% sure about that. Differential Revision: https://phab.mercurial-scm.org/D6135
-
- Mar 15, 2019
-
-
Gregory Szorc authored
My editor accidentally wrote CRLF line endings because I authored this code on Windows. Derp. I'm kinda surprised no linters caught this... # no-check-commit to avoid false positive for foo_bar names Differential Revision: https://phab.mercurial-scm.org/D6134
-
- Mar 13, 2019
-
-
Martin von Zweigbergk authored
The only valid API since 265e91da56fd (dirstate: drop deprecated methods (API), 2018-02-02) is the context manager returned from dirstate.parentchange(). Differential Revision: https://phab.mercurial-scm.org/D6126
-
- Mar 09, 2019
-
-
Ian Moody authored
Otherwise ch is the int value of the byte in py3 rather than the actual character. Differential Revision: https://phab.mercurial-scm.org/D6103
-
- Mar 14, 2019
-
-
Martin von Zweigbergk authored
When using regular on-disk rebase, filectx.markcopies() calls to dirstate.copy(), which happily records the copy. Then it's simply ignored if it doesn't matter for the commit (as in the test case I added in the previous patch). Let's do the same for overlayworkingctx. Differential Revision: https://phab.mercurial-scm.org/D6133
-
Martin von Zweigbergk authored
In the added test case, there is a merge commit that has one obsolete parent with a rename. Since the rename is not in the other parent, pathcopies() from that other parent will include the copy. Then when we try to rebase this merge commit onto another commit that has the same content changes, but no tracking of the rename (because it was done with "hg remove; hg add" instead of "hg mv"), we try to propagate the copy information. That fails because overlayworkingctx expects a file to be modified if it's going to have copy information. Differential Revision: https://phab.mercurial-scm.org/D6132
-
Pierre-Yves David authored
Before this change, the --clear flag was not clearing the on disk cache. (We also remove the extra verbosity when using --clear. Same as what we did for --add)
-
Pierre-Yves David authored
This is an LRU cache, let us make sure of that.
-
Pierre-Yves David authored
Let makes sure the cache can hold multiple value.
-
Pierre-Yves David authored
Simple sanity check.
-
Pierre-Yves David authored
If the command invocation is about adding a new entry, we should remain terse (the same as we do for many commands).
-
Pierre-Yves David authored
Not doing so had two consequences: 1) the command cannot be run on read only repositories, 2) when using --add on an empty cache, the command crash prematurely trying to read the cache file on disk.
-
Pierre-Yves David authored
Removing more capital letters. The output will get a test once other issues get fixed.
-
Pierre-Yves David authored
The message was lacking an end of line. In addition we do not capitalize output in Mercurial.
-
- Dec 27, 2018
-
-
Kyle Lippincott authored
Differential Revision: https://phab.mercurial-scm.org/D6121
-
- Mar 11, 2019
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D6120
-
Martin von Zweigbergk authored
The function should be applicable generically when moving from one commit to another. I'll try to add more callers when I find time. I'm not convinced it's handling all the cases correctly, but we should have a generic function for this kind of operation, so I think it belongs somewhere in core (not in the uncommit extension). Differential Revision: https://phab.mercurial-scm.org/D6119
-
Martin von Zweigbergk authored
I want to add a dependency from scmutil.copies(), so I need to remove this dependency first. Differential Revision: https://phab.mercurial-scm.org/D6118
-
Martin von Zweigbergk authored
_fixdirstate() already also updates to the given commit, so let's rename it to _movedirstate(). Also update the documentation and drop the unnecessary "curctx" argument, since that should always be repo['.']. Differential Revision: https://phab.mercurial-scm.org/D6117
-
Pierre-Yves David authored
Resolving any name requires the tags cache to be warm. We make sure that `hg debugupdatecache` warm the tag cache entry too.
-
Pierre-Yves David authored
We are in the "full" case, so we better warm everything we can.
-
- Feb 13, 2019
-
-
Sushil Khanchi authored
This patch fix the behaviour of fullcopytracing algorithm in the case when both the merging csets are not the descendant of merge base. Although it seems to be the rare case when both the csets are not descendant of merge base. But it can be seen in most of cases of content-divergence in evolve extension, where merge base is the common predecessor. Previous patch added a test where this algorithm can fail to continue because of an assumption that only one of the two csets can be dirty. This patch fix that error. For refrence I suggest you to look into the previous discussion held on a patch sent by Pulkit: https://phab.mercurial-scm.org/D3896 Differential Revision: https://phab.mercurial-scm.org/D5963
-
- Feb 14, 2019
-
-
Sushil Khanchi authored
This patch is a part of series which is about the case when both the merging csets are not descendant of merge base. The existing code assumes if c1 is dirty there shouldn't be any partial copies from c2 i.e both2['incomplete'] and same for c2, if c2 is dirty both1['incomplete'] should be empty, but this is not the right assumption. Now as we know we can have both c1 and c2 dirty at the same time, it is possible that c1 is dirty and both2['incomplete'] has some value. Or if c2 is dirty and both1['incomplete'] has some value. Added test shows that because of this assumption it could fail. Differential Revision: https://phab.mercurial-scm.org/D5962
-
Sushil Khanchi authored
This series of patches is to cover a case in fullcopytracing algorithms where both the merging csets are not descendant of merge base. In this algorithm we call a merging cset "dirty" if that cset is not the descendant of merge base. That said, added test in this patch cover case when both the merging csets are "dirty". Actually this case of "both dirty" was encountered by Pulkit when he was working on content-divergence where it is possible that both the csets are not descendant of merging base. For reference you can look into: https://phab.mercurial-scm.org/D3896 As this test run fine without any error and correctly traced the copies, I added this test to make sure that it doesn't break even after I will modify some code in next patches to fix an error. Next patch adds the tests where this algorithm throws an error for the same case of "both dirty". Differential Revision: https://phab.mercurial-scm.org/D5961
-
- Mar 10, 2019
-
-
Matt Harbison authored
Similar to 92055d539e49.
-
Pierre-Yves David authored
A reflink copy will copy the files "as usual" but keep using the same data block underneath. This is only supported by "copy on write" file system like btrfs or zfs. This will achieve similar performance that the existing hardlink clone that Mercurial performs with the same initial space saving. However, it will behave better on revlogs start being touch by strip. Instead of duplicating all data in the touched revlogs, only the block actually affected by the strip will be duplicated. This save a lot of space when building many variants of large repositories. The --reflink=always flag make sure the `cp` call fails if reflink copies are not supported. Falling back to local clone.
-
Pierre-Yves David authored
-
Pierre-Yves David authored
This makes it easier to update this duplicated code. (we do a small output fix as we go)
-