automation: correct the path separator in LIBPATH on Windows
I haven't tried building the x86 installer, but happened to notice this when
working on the thg installer. Experimenting in PowerShell seems to show that
LIBPATH was expanded at the end, but with ':' between, it effectively corrupted
`${root}\WinSDK\Lib` and the first path in LIBPATH.
Differential Revision: https://phab.mercurial-scm.org/D6642
abort: added support for merge
This adds support of `hg merge --abort` to `hg abort` plan.
This involves refactoring `hg.merge` into two different
functions removing the abort logic of `merge` from `hg.merge`
and then creating a seperate `hg.abortmerge` to handle the
abort logic so that the abortion of merge can be called
independently.
`hg.abortmerge` is then registered as `abortfunc` for the
state detection API so that `commands.abort` can use it to
deal with an unfinished merge operation.
Results are shown as tests.
Differential Revision: https://phab.mercurial-scm.org/D6588
abort: added support for unshelve
This patch adds the support for shelve in `hg abort` plan.
For this the logic to load a `shelvedstate` and the error
handling for it had been shifted to a seperate function
`_loadunshelvedstate()`. This returns a tuple with `state` file
and `opts.`
`hgabortunshelve()` has been created for independent calls.
In case abortion of `unshelve` is called via `hg abort` the
`shelvedstate` needs to be loaded seperately. This has been
ensured by `_loadunshelvedstate()`
`hgabortunshelve()` is then registered as `abortfunc` for state
detection API.
Results are shown as tests.
Differential Revision: https://phab.mercurial-scm.org/D6579
unshelve: changed Corruptedstate error msg from ui.warn to error.Abort
This changes the message type of Corruptedstate error in case of `hg unshelve --abort`
to error.Abort from warning message. This is done so as to avoid the return statement
after the warning.
Differential Revision: https://phab.mercurial-scm.org/D6636
mq: fix for merge detection methods
Differential Revision: https://phab.mercurial-scm.org/D6548
py3: store _origdoc as str
Since __doc__ is str, it seems natural that _origdoc also is.
Differential Revision: https://phab.mercurial-scm.org/D6623
copies: follow copies across merge base without source file (
issue6163)
As in the previous patch, consider these two histories:
@ 4 'rename x to y'
|
o 3 'add x again'
|
o 2 'remove x'
|
| o 1 'modify x'
|/
o 0 'add x'
@ 4 'rename x to y'
|
o 3 'add x again'
|
| o 2 'modify x'
| |
| o 1 'add x'
|/
o 0 'base'
We trace copies from the 'modify x' commit to commit 4 by going via
the merge base (commit 0). When tracing file 'y' (_tracefile()) in the
first case, we immediately find the rename from 'x'. We check to see
if 'x' exists in the merge base, which it does, so we consider it a
valid copy. In the second case, 'x' does not exist in the merge base,
so it's not considered a valid copy. As a workaround, this patch makes
it so we also attempt the check in mergecopies's base commit (commit 1
in the second case). That feels pretty ugly to me, but I don't have
any better ideas.
Note that we actually also check not only that the filename matches,
but also that the file's nodeid matches. I don't know why we do that,
but it was like that already before I rewrote mergecopies(). That
means that the rebase will still fail in cases like this (again, it
already failed before my rewrite):
@ 4 'rename x to y'
|
o 3 'add x again with content X2'
|
o 2 'remove x'
|
| o 1 'modify x to content X2'
|/
o 1 'modify x to content X1'
|
o 0 'add x with content X0'
Differential Revision: https://phab.mercurial-scm.org/D6604