shelve: actually test corrupted shelve state The test was previous moving the corrupted shelve state file as an histedit state file. Differential Revision: https://phab.mercurial-scm.org/D3690

shelve: directly handle `--continue` Shelve is currently sub-contracting some of its work to the rebase extension. In order to make shelve more independent and flexible we would like shelve to handle the parent alignment directly. This changeset takes on the next step, handling the abort process. Same as for --abort. It turns out we have all the necessary bits in the `shelvestate` file. So we do not need anything from the interrupted rebase. Differential Revision: https://phab.mercurial-scm.org/D3689

shelve: directly handle the abort process Shelve is currently sub-contracting some of its work to the rebase extension. In order to make shelve more independent and flexible we would like shelve to handle the parent alignment directly. This change starts with the simplest bits, handling the abort process. It turns out we have all the necessary bits in the `shelvestate` file. So we do not need anything from the interrupted rebase. As a nice side effect, a test about missing `shelverebasestate` state file now behave better. Differential Revision: https://phab.mercurial-scm.org/D3688

shelve: check the actual shelvestate in morestatus The rebasestate is a lower level implementation details that we are trying to remove. Differential Revision: https://phab.mercurial-scm.org/D3687

packaging: dynamically define make targets We currently have make boilerplate for each instance of a distro's release. This is redundant, annoying to maintain, and prone to errors. This commit defines variables holding available releases for various distros. We then iterate through the list and dynamically define make targets. Differential Revision: https://phab.mercurial-scm.org/D3761

packaging: don't write files for templatized Dockerfiles Now that Docker image building is implemented in Python and we can perform template substitution in memory, we don't need to write out produced Dockerfiles to disk. Differential Revision: https://phab.mercurial-scm.org/D3760

packaging: replace dockerlib.sh with a Python script I want to do some more advanced things with Docker in upcoming commits. Trying to do that with shell scripts will be a bit too painful for my liking. Implementing things in Python will be vastly simpler in the long run. This commit essentially ports dockerlib.sh to a Python script. dockerdeb and dockerrpm have been ported to use the new hg-docker script. hg-docker requires Python 3. I've only tested on Python 3.5. Unlike the local packaging scripts which may need to run on old distros, the Docker packaging scripts don't have these constraints. So I think it is acceptable to require Python 3.5. As part of the transition, the Docker image tags changed slightly. I don't think that's a big deal: the Docker image names are effectively arbitrary and are a means to an end to achieve running commands in Docker containers. The code for resolving the Dockerfile content allows substituting values passed as arguments. This will be used in a subsequent commit. Differential Revision: https://phab.mercurial-scm.org/D3759

packaging: consistently create build user in Dockerfiles Previously, dockerlib.sh appended some commands to create a "build" user in each Docker image. The resulting Docker images could be inconsistent depending on the execution environment and base image. With this change, we explicitly create our custom user and group as the first action in each Dockerfile. The user always has user:group 1000:1000 and all built images are consistent. We also create a home directory for the user under /build. This directory is currently ignored. As part of this, we stop setting the DBUILDUSER variable in dockerlib.sh and instead set it in the respective scripts that call it. This is in preparation for further refactoring of dockerlib.sh. Differential Revision: https://phab.mercurial-scm.org/D3758

scmutil: move construction of instability count message to separate fn When the commad we are running, introduces new instabilities, we show a message like `5 new orphan changesets`, `2 new content-divergent changesets`, `1 new phase-divergent changesets` etc which is very nice. Now taking a step ahead, we want users to show how to fix them too. Something like: `5 new orphan changesets (run 'hg evolve' to resolve/stabilize them)` `2 new content-divergent changesets (run 'hg evolve --content-divergent' to resolve them)` and maybe telling user a way to understand more about those new instabilities like `hg evolve --list` or `hg log -r 'orphan()'` something like that. The idea came from issue5855 which I want to fix because fixing that will result in a nice UI. Taking the construction logic out will allow extensions like evolve (maybe rebase too) to wrap that and add information about how to resolve and how to understand the instability more. Differential Revision: https://phab.mercurial-scm.org/D3734

procutil: use unbuffered stdout on Windows Windows doesn't support line buffering, treating it as fully buffered. This causes output of slow commands to stutter. We use unbuffered instead.