Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 20 Mar 2019 20:39:44 +0300] rev 41989
store: recommend using `hg debugrebuildfncache` is fncache is corrupted
Differential Revision: https://phab.mercurial-scm.org/D6160
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 18 Mar 2019 14:48:49 +0300] rev 41988
debugsparse: abort if the repository is not sparse instead of ui.status()
This is similar to what narrow extension does.
Differential Revision: https://phab.mercurial-scm.org/D6149
Martin von Zweigbergk <martinvonz@google.com> [Tue, 12 Mar 2019 14:17:41 -0700] rev 41987
revert: option to choose what to keep, not what to discard
I know the you (the reader) are probably tired of discussing how `hg
revert -i -r .` should behave and so am I. And I know I'm one of the
people who argued that showing the diff from the working copy to the
parent was confusing. I think it is less confusing now that we show
the diff from the parent to the working copy, but I still find it
confusing. I think showing the diff of hunks to keep might make it
easier to understand. So that's what this patch provides an option
for.
One argument doing it this way is that most people seem to find `hg
split` natural. I suspect that is because it shows the forward diff
(from parent commit to the commit) and asks you what to put in the
first commit. I think the new "keep" mode for revert (this patch)
matches that.
In "keep" mode, all the changes are still selected by default. That
means that `hg revert -i` followed by 'A' (keep all) (or 'c' in
curses) will be different from `hg revert -a`. That's mostly because
that was simplest. It can also be argued that it's safest. But it can
also be argued that it should be consistent with `hg revert -a`.
Note that in this mode, you can edit the hunks and it will do what you
expect (e.g. add new lines to your file if you added a new lines when
editing). The test case shows that that works.
Differential Revision: https://phab.mercurial-scm.org/D6125
Martin von Zweigbergk <martinvonz@google.com> [Tue, 12 Mar 2019 14:58:35 -0700] rev 41986
patch: include newline at EOF in help text for interactive patch
The lack of a newline means that some "editors" that are useful in
tests, such as `echo "+new line" >> "$1"` don't work. It's obviously
easy to work around it, but newline at EOF seems like a good practice
anyway.
Differential Revision: https://phab.mercurial-scm.org/D6124
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 19 Mar 2019 16:36:59 +0300] rev 41985
merge with stable
Augie Fackler <raf@durin42.com> [Tue, 19 Mar 2019 09:23:35 -0400] rev 41984
Added signature for changeset
4ea21df312ec
Augie Fackler <raf@durin42.com> [Tue, 19 Mar 2019 09:23:33 -0400] rev 41983
Added tag 4.9.1 for changeset
4ea21df312ec
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 03 Mar 2019 20:16:22 +0530] rev 41982
patch: include flag-only file changes in "special" when filtering (
issue5864)
This patch fix the
issue5864 (or maybe
issue5865 too) which occurs during
split (or I should say at the time of filtering the hunks in interactive
mode) where user hits a not ending loop of "no changes to record".
And it's not only the case for split it will happen in every interactive
case for e.g. `hg commit -i` or `hg uncommit -i`
After looking into code I found that when filtering we have some
notation called "special" for the file headers which doesn't contain
any hunk and just contain the header (for e.g. newly added empty file
or deleted file) where the user cannot change the content of operation.
And I think we can put this "flag-only" file change in that same bucket
of "special". But I doubt a bit about the case when a file have flag change
and atleast one hunk then user won't be able to separate the flag change
from hunks.
Changed test file reflect the fixed behaviour.
Differential Revision: https://phab.mercurial-scm.org/D6058
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 18 Mar 2019 16:56:24 +0300] rev 41981
store: error out if fncache does not ends with a newline
If fncache does not ends with a newline, chunk will not be fully consumed. It
should be a bug somewhere or the fncache is corrupted if that happens. Let's
error out in such cases.
Differential Revision: https://phab.mercurial-scm.org/D6148
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 18 Mar 2019 14:57:43 +0300] rev 41980
tracked: add documentation about `--import-rules` flag
The documentation is inspired from the `--import-rules` flag of hg debugsparse
command.
Differential Revision: https://phab.mercurial-scm.org/D6150
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 19:13:45 +0000] rev 41979
discovery: fix embarrassing typo in slice definition
The code introduced in
e514799e4e07 ended up having a silly bug. The indexing
selected a single item slice picking only p1. The discovery result was still
correct, but the sampling was hampered, sometime leading to much more round
trips being performed.
Fixing this issue restore the previous sampling behavior.
This fix has a negative performance impact on the pathological case the previous
test has been built.
# parent of this changesets
! wall 5.313884 comb 5.310000 user 5.260000 sys 0.050000 (best of 5)
! wall 6.711860 comb 6.710000 user 6.670000 sys 0.040000 (max of 5)
! wall 5.844016 comb 5.842000 user 5.784000 sys 0.058000 (avg of 5)
! wall 5.778635 comb 5.780000 user 5.740000 sys 0.040000 (median of 5)
# With this changesets.
! wall 6.350879 comb 6.350000 user 6.300000 sys 0.050000 (best of 5)
! wall 6.653647 comb 6.660000 user 6.480000 sys 0.180000 (max of 5)
! wall 6.492762 comb 6.494000 user 6.414000 sys 0.080000 (avg of 5)
! wall 6.547577 comb 6.550000 user 6.490000 sys 0.060000 (median of 5)
Changeset
e514799e4e07 raised the question of using the "_uncheckedparentrevs"
instead of the current code. So I ran comparative timing:
# old code:
55919b96c02a (
e514799e4e07 parent)
! wall 64.078708 comb 64.080000 user 63.160000 sys 0.920000 (best of 5)
! wall 68.296300 comb 68.290000 user 67.410000 sys 0.880000 (max of 5)
! wall 65.899075 comb 65.894000 user 65.082000 sys 0.812000 (avg of 5)
! wall 66.140286 comb 66.130000 user 65.330000 sys 0.800000 (median of 5)
# buggy code:
e514799e4e07
! wall 46.605362 comb 46.610000 user 45.880000 sys 0.730000 (best of 5)
! wall 48.619659 comb 48.620000 user 47.890000 sys 0.730000 (max of 5)
! wall 47.350247 comb 47.350000 user 46.672000 sys 0.678000 (avg of 5)
! wall 46.983224 comb 46.980000 user 46.350000 sys 0.630000 (median of 5)
# fixed code:
e514799e4e07 with this fix
! wall 55.858460 comb 55.850000 user 55.090000 sys 0.760000 (best of 5)
! wall 59.048805 comb 59.060000 user 58.110000 sys 0.950000 (max of 5)
! wall 57.192639 comb 57.192000 user 56.350000 sys 0.842000 (avg of 5)
! wall 57.056373 comb 57.060000 user 56.160000 sys 0.900000 (median of 5)
# version using uncheckedparents
! wall 56.471916 comb 56.470000 user 55.630000 sys 0.840000 (best of 5)
! wall 58.228793 comb 58.230000 user 57.600000 sys 0.630000 (max of 5)
! wall 57.377583 comb 57.378000 user 56.674000 sys 0.704000 (avg of 5)
! wall 57.008843 comb 57.010000 user 56.330000 sys 0.680000 (median of 5)
So it looks like the overhead from `_uncheckedparentrevs` is not that impactful.
I'll investigate this shortly. I'm almost done updating our benchmark suite
with more meaningful discovery cases.
Pulkit Goyal <pulkit@yandex-team.ru> [Thu, 22 Nov 2018 15:14:24 +0300] rev 41978
store: don't read the whole fncache in memory
In large repositories with lot of files, the fncache grows more than 100 MB and
reading that whole thing into memory slows things down. Let's not read the whole
thing into memory.
This patch changes fncache loading code to read 1 MB at once. Loading 1 MB at
once saves ~1 sec on perffncacheload for our internal repository. I tried
various values such as 0.5 MB, 5 MB, 10 MB but best results were produced using
1 MB as the chunksize.
On a narrow clone with fncache around 40 MB, this patch saves ~0.04 seconds on
average on perffncacheload.
To test the code, I have coded an extension in test-fncache.t which set
chunksize to 1 byte, and the test passes with that.
Differential Revision: https://phab.mercurial-scm.org/D5296
Matt Harbison <matt_harbison@yahoo.com> [Sat, 16 Mar 2019 14:40:21 -0400] rev 41977
record: prevent commits that don't pick up dirty subrepo changes (
issue6102)
This path covers interactive mode for commit, amend, and shelve, as well as the
deprecated record extension. Since shelf creation uses commit without -S in the
non-interactive case, aborting here should be OK. (I didn't check what happens
to non interactive shelve creation if `ui.commitsubrepos=True` is set.)
subrepoutil.precommit() will abort on a dirty subrepo if the config option isn't
set, but the hint recommends using --subrepos to commit. Since only the commit
command currently supports that option, the error has to be raised here to omit
the hint.
Doing the check before asking about all of the hunks in the MQ test seems like
an improvement on its own. There's probably an additional check on this path
that can be removed.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 08 Mar 2019 10:20:33 -0800] rev 41976
wix: restore COPYING.rtf
8427fea04017 accidentally blew away the content of this file.
As part of restoring the content, I updated the copyright year
to 2019.
Differential Revision: https://phab.mercurial-scm.org/D6098
Yuya Nishihara <yuya@tcha.org> [Sun, 17 Mar 2019 12:43:45 +0900] rev 41975
test-https: add some more known failure messages of client certs (
issue6030)
I don't think the exact error message is important here. On Debian sid,
ECONNRESET is raised, and "[SSL] tlsv13 alert certificate required" on NetBSD.
Yuya Nishihara <yuya@tcha.org> [Sun, 17 Mar 2019 12:37:57 +0900] rev 41974
test-https: turn off system OpenSSL configuration
This mostly fixes the test failure on Debian sid where TLS 1.0 and 1.1 are
disabled by default.
https://sources.debian.org/patches/openssl/1.1.1a-1/Set-systemwide-default-settings-for-libssl-users.patch/
$OPENSSL_CONF could be set by run-tests.py, but the other tests should work
without a "legacy" TLS, so I decided to not.
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 27 Feb 2019 16:29:48 +0300] rev 41973
store: move logic to check for invalid entry in fncache to own function
This helps separate the original reading logic from the one which finds for an
invalid entry.
Differential Revision: https://phab.mercurial-scm.org/D6030
Ian Moody <moz-ian@perix.co.uk> [Sat, 09 Mar 2019 02:52:49 +0000] rev 41972
py3: add test-phabricator.py to python3-whitelist
Differential Revision: https://phab.mercurial-scm.org/D6114
Ian Moody <moz-ian@perix.co.uk> [Sat, 09 Mar 2019 02:18:49 +0000] rev 41971
py3: convert to/from bytes/unicode for json.(dump|load)s in debugcallconduit
Differential Revision: https://phab.mercurial-scm.org/D6113
Ian Moody <moz-ian@perix.co.uk> [Fri, 08 Mar 2019 18:30:12 +0000] rev 41970
py3: use pycompat.byteskwargs on opts in phabricator.py
Differential Revision: https://phab.mercurial-scm.org/D6107
Boris Feld <boris.feld@octobus.net> [Fri, 21 Dec 2018 17:12:39 +0100] rev 41969
watchman: ignore some of watchman errors
Don't display 'illegal_fstypes' errors. In environments with network
filesystems, the error messages are quickly pilling up and polluting outputs.
Differential Revision: https://phab.mercurial-scm.org/D5955
Boris Feld <boris.feld@octobus.net> [Fri, 21 Dec 2018 17:10:54 +0100] rev 41968
watchman: add the possibility to set the exact watchman binary location
This is necessary to make rolling releases of new watchman versions across
users.
Differential Revision: https://phab.mercurial-scm.org/D5954
Martin von Zweigbergk <martinvonz@google.com> [Fri, 15 Mar 2019 22:18:35 -0700] rev 41967
context: use wdirhex constant instead of calculating it
Differential Revision: https://phab.mercurial-scm.org/D6143
Martin von Zweigbergk <martinvonz@google.com> [Wed, 13 Mar 2019 11:30:04 -0700] rev 41966
split: use the new movedirstate() we now have in scmutil
This avoids unnecessarily touching the working copy when splitting the
parent of the working copy. That also makes the test-removeemptydirs.t
case invalid, so we can just delete it.
Differential Revision: https://phab.mercurial-scm.org/D6127
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 00:40:11 +0000] rev 41965
manifestcache: use `wcache` directory for manifest cache
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`.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 15 Mar 2019 15:07:43 +0000] rev 41964
manifestcache: protect write with `wlock` instead of `lock`
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 09:12:55 +0000] rev 41963
manifestcache: clear the cache before testing the debug command
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 15 Mar 2019 12:17:30 +0000] rev 41962
manifestcache: abstract the filename in a class attribute
This make the code clearer and simpler to update.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 15 Mar 2019 09:07:23 +0000] rev 41961
manifestcache: skip setup earlier if we don't have the lock
There a no point preparing a closure if we are not going to use it.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 11:46:18 +0000] rev 41960
manifestcache: test the cache is warm after a commit
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 15 Mar 2019 13:52:36 +0000] rev 41959
manifestcache: stop altering the lru cache order while displaying it
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 <pierre-yves.david@octobus.net> [Fri, 15 Mar 2019 13:52:56 +0000] rev 41958
manifestcache: support multiple cache addition in one debug command run
This is more practical.
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 18:11:22 -0700] rev 41957
wix: autogenerate wxs file for library files
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 <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 17:59:51 -0700] rev 41956
wix: introduce variable to hold path to wix packaging directory
For convenience.
Differential Revision: https://phab.mercurial-scm.org/D6138
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 18:25:23 -0700] rev 41955
wix: package missing .dll and .pyd files
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 <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 18:25:07 -0700] rev 41954
setup: exclude crypt32.dll in py2exe builds
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
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 13:27:37 -0700] rev 41953
packaging: don't bundle DLLs in py2exe library.zip for x86 builds
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
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 18:14:33 -0700] rev 41952
packaging: convert files to LF
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
Martin von Zweigbergk <martinvonz@google.com> [Wed, 13 Mar 2019 10:51:40 -0700] rev 41951
dirstate: remove obsolete reference to dirstate.beginparentchange
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
Ian Moody <moz-ian@perix.co.uk> [Sat, 09 Mar 2019 00:44:26 +0000] rev 41950
py3: use pycompat.iterbytestr to convert memoryview slice to bytestring
Otherwise ch is the int value of the byte in py3 rather than the actual
character.
Differential Revision: https://phab.mercurial-scm.org/D6103
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Mar 2019 14:46:29 -0700] rev 41949
rebase: fix crash with in-memory rebase and copies
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 <martinvonz@google.com> [Thu, 14 Mar 2019 13:53:20 -0700] rev 41948
test: demonstrate crash with in-memory rebase and copies
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 <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 09:12:46 +0000] rev 41947
manifestcache: actually honor --clear
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 <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 10:58:53 +0000] rev 41946
manifestcache: make sure the entry are ordered by access time
This is an LRU cache, let us make sure of that.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 09:12:27 +0000] rev 41945
manifestcache: adding a second distinct entry
Let makes sure the cache can hold multiple value.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 10:53:28 +0000] rev 41944
manifestcache: test that adding the same entry twice do not duplicates it
Simple sanity check.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 09:11:41 +0000] rev 41943
manifestcache: do not display data when using --add
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 <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 10:43:01 +0000] rev 41942
manifestcache: only lock the repository if the debug command touch the cache
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 <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 10:24:51 +0000] rev 41941
manifestcache: further fix to debug command output
Removing more capital letters. The output will get a test once other issues get
fixed.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 09:11:18 +0000] rev 41940
manifestcache: test and fix some output of the debug command
The message was lacking an end of line. In addition we do not capitalize output
in Mercurial.
Kyle Lippincott <spectral@google.com> [Thu, 27 Dec 2018 13:36:17 -0800] rev 41939
chunkselector: fix typos in instructions when user reviews patch
Differential Revision: https://phab.mercurial-scm.org/D6121
Martin von Zweigbergk <martinvonz@google.com> [Mon, 11 Mar 2019 14:04:48 -0700] rev 41938
scmutil: document matcher argument of movedirstate()
Differential Revision: https://phab.mercurial-scm.org/D6120
Martin von Zweigbergk <martinvonz@google.com> [Mon, 11 Mar 2019 09:42:29 -0700] rev 41937
uncommit: move _movedirstate() to scmutil for reuse
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 <martinvonz@google.com> [Mon, 11 Mar 2019 09:20:26 -0700] rev 41936
copies: remove dependency on scmutil by directly using match.exact()
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 <martinvonz@google.com> [Mon, 11 Mar 2019 09:35:36 -0700] rev 41935
uncommit: convert _fixdirstate() into _movedirstate()
_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 <pierre-yves.david@octobus.net> [Mon, 11 Mar 2019 02:34:12 +0100] rev 41934
updatecaches: also warm the tags caches
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 <pierre-yves.david@octobus.net> [Mon, 11 Mar 2019 02:32:21 +0100] rev 41933
updatecaches: also warm revbranchcache for filtered revisions
We are in the "full" case, so we better warm everything we can.
Sushil khanchi <sushilkhanchi97@gmail.com> [Wed, 13 Feb 2019 15:50:14 +0530] rev 41932
copies: handle a case when both merging csets are not descendant of merge base
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
Sushil khanchi <sushilkhanchi97@gmail.com> [Thu, 14 Feb 2019 16:09:43 +0530] rev 41931
copies: add test that makes both the merging csets dirty and fails
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 <sushilkhanchi97@gmail.com> [Thu, 14 Feb 2019 17:11:35 +0530] rev 41930
copies: add test that makes both the merging csets dirty and run w/o error
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