test-compat: merge mercurial-4.8 into mercurial-4.7

test-compat: merge mercurial-4.9 into mercurial-4.8

test-compat: merge mercurial-5.0 into mercurial-4.9

test-compat: don't run the py3 test on the older branches

docs: add missing Figure 10 to sharing.rst The .svg file itself has been already added earlier.

test-compat: merge mercurial-4.7 into mercurial-4.6

test-compat: merge mercurial-4.8 into mercurial-4.7

test-compat: merge mercurial-4.9 into mercurial-4.8

test-compat: merge mercurial-5.0 into mercurial-4.9

test-compat: merge mercurial-5.1 into mercurial-5.0

test-compat: merge stable into mercurial-5.1

heptapod-ci: add a script to map evolve branch to mercurial revision for tests map-hg-rev.sh can be tested using this command: ```sh for i in $(hg log -T '{branch}\n' | sort -u); do echo $i $(testlib/map-hg-rev.sh $i) done ```

pytype: ignore abc.ABCMeta metaclasses that don't work on py3 See 70d42e2ad9b4 in hg: We can remove this when we're Python 3-only, but for now it's just too awkward to deal with and it's harmless.

tests: remove extra whitespace before patch in obslog output The indent() template function was fixed in https://phab.mercurial-scm.org/D7432 so now we have less trailing whitespace in obslog output. CORE-TEST-OUTPUT-UPDATE: fa246ada356b

branching: merge with stable

changelog: add a couple of missing entry about the next feature release

changelog: fix entry in the wrong location That change was made on default, not stable.

changelog: add a wheelbarrow of missing entries

heptapod-ci: simpler CI We have a mercurial clone available in the docker image now. This will same some time to avoid a full Mercurial clone for each run.

heptapod-ci: run the test with color This make the result easier to read.

compat: compatibility for cl.nodemap.get vs cl.index.get_rev

compat: compatibility for pathuril.dirs vs util.dirs

obslog: phase divergence fix for 5c41bb482867 I forgot to pull the latest version before publishing the topic :-(

obslog: phase divergence fix for b135591bec1a I forgot to pull the latest version before publishing the topic :-(

obslog: make {descdiff} not be indented and leave that to the template Same idea as the previous patch and same explanation for changes to the test case.

obslog: make {patch} not be indented and leave that to the template This removes some unwanted indentation from the tests. In the first case, it's because indent() doesn't indent a blank line. In the second case, it's because we used templating with {patch} and had not requested indentation (but we still got it before this patch). Note that tests will only pass with a very recent Mercurial (one with https://phab.mercurial-scm.org/D7432 applied).

obslog: make {succnodes} be full hex nodes It should be up to the user to shorten the nodeid as much or as little as they like.

obslog: remove now-unused code for plain styling We now always use a non-plain formatter for the non-local-filtering code paths, so we can remove the code for plain styling. I couldn't figure out how to replace the fm.formatlist() by something less about formatting, so I've only removed the irrelevant arguments from those calls.

obslog: redefine default output as a template, unless -f was given This was easier than I expected to do without affecting any test output at all. `hg obslog -f` is pretty broken with templating. For example, it inserts a single "date" field, but it provides two values for it if the dates are different. That results in a traceback when running e.g. `hg obslog -f -Tfoo` with non-local obsmarkers with different dates. We need to figure out what we want to put in the template for the filtered case. I've just left it out for now.

obslog: add newline after all markers in non-graphlog to match graphlog I'd also be fine with doing the reverse if that's preferred, but I really want them to be the same so they can use the same template.

obslog: make reason for unavailable patch part of template We need the reason to be in the template in order to be able to templatize the whole output.

obslog: make content and description patches available to templater The code was repeatedly calling fm.write() with the same field ("patch" and "descdiff"). I think that led to the value constantly getting replaced, so when it was used in a template (as {patch} or {descdiff}), it would only get the last value, which was always an empty string. This patch fixes it by writing the full patch to a temporary buffer and then assigning the whole patch to the formatter field.

obslog: rename {desc-diff} to {descdiff} since the former is invalid

tests: demonstrate broken {patch} and {desc-diff} template keywords

topic: drop compat.successorssets(), it's not used The only place in topics that uses successorssets function is in evolvebits.py, and it's using that function from obsutil directly.

topic: drop compat.getmarkers() and use obsutil.getmarkers() directly The function in question was moved from obsolete to obsutil in a14e2e7f7d1f (hg 4.3). See also 6aff4bb3970d for hgext3rd/evolve.

cmdrewrite: avoid accessing scmutil.status fields by index Support for indexed access is going away in Mercurial. Accessing the fields by name is clearer anyway.

obslog: avoid using a formatter after calling end() on it I don't know if makes a difference, but it feels wrong to use it after calling end(). We can simply use the parent formatter in this case.

obslog: use plural name "effects" for list of all effects Same reasoning as the previous patch, but here the singular was used for the list instead. This patch also renames the variable that represents the list of effects to plural "effects" to reduce confusion.

obslog: use singular name "succnode" for each element of {succnodes} The name that we pass for formatlist() is the name of each element. After this patch, you'll write '{succnodes % "{succnode}"}' instead of the confusing '{succnodes % "{succnodes}"}' (where the two "succnodes" refer to different things. Users can write templates that are compatible across this change by using e.g. '{succnodes % "{if(succnode, succnode, succnodes)}"}'.

docs: add SVG figures for sharing.rst Generated by graphviz loosely based on .dot files produced by dotgraph extension.

docs: add some up-to-date output from push/pull commands Hopefully it's going to be helpful for users to better understand how evolve works.

docs: add two more amend commits to simulate temporary amend commits sharing.rst made reference to temporary amend commits and used them to demonstrate that hidden commits are not exchanged. Nowadays, evolve doesn't create such commits, but it still makes sense to show how they are handled during the exchange process. So let's add two more amend commits, one for each repo. This way the guide doesn't have to be updated too much, but doesn't lose this important detail of working with evolve. Unfortunately, this means that tons of hashes change, but it's better than to have figure 4 demonstrate absolutely nothing. Temporary amend commits were removed from test-sharing.t in 06844693bb21, but sharing.rst continued using them for demonstration purposes. It might've been better to replace at least some of the temporary amend commits by extra amends back then, but oh well.

docs: revision numbers are technically stable From `hg help glossary`: "Note that the revision number may be different in each clone of a repository." But cloning the same repo multiple times yields the same result, and that shows that revision numbers are stable.

tests: remove a repeated statement We looked at the review repo just 6 lines above.

docs: correct node hashes in sharing.rst based on test-sharing.t

tests: add shortlog of other repos to test-sharing.t The figures require showing multiple repos, so let's show them all, even if they look trivial.

tests: use |shortest in test-sharing.t because sharing.rst uses it

compat: compatibility for cl.nodemap.get vs cl.index.get_rev

compat: compatibility for pathuril.dirs vs util.dirs

branching: merge with stable

heptapod-ci: test with python3 too

heptapod-ci: add a --pure variant for the CI The end goal is to migrate all piece of the evolve CI currently en Jenkins.

heptapod-ci: let the number of CPU to be picked automatically We now have a larger, bigger machine to run the tests. Let's let run-tests.py pick the number of concurrent jobs.

heptapod-ci: point to our own docker images Lets step further into the future.

readme: update contribution guide We move to heptapod !

branching: merge with stable

docs: remove --all from hg evolve, since it's been the default for some time

docs: typo in user-guide.rst

obslog: don't overwrite {rev} keyword from changeset context Now that we have the whole changeset in the formatter context, there's no need to explicitly add {rev}. We should also deprecate the {shortdescription} keyword since it's no longer needed, but I don't know how to do that.

obslog: make changeset available to templater obslog templating currently has very limited support for templating the precursor changeset (when available). The only available keywords are {node}, {rev}, and {shortdescription}. This patch makes the entire changeset available to the templater by passing it to formatter.context(). That function has been available since Mercurial 4.2.

tests: simplify by pruning unwanted changesets a little earlier The pruned commits are not relevant to the test case, so let's clean them up at the end of the previous test case instead of part-way through the next one.

evolve: use more often seen metavariables in command synopsis strings Also use ellipsis when multiple options are acceptable.

topic: add more options to command synopsis string

debian: also build with python3 We build with Python 3 along with Python 2. The binary package will contain the extension for both python version. This is to ease transition until the mercurial package in Debian uses Python 3. The documentation is still built with Python 2 because it needs Mercurial (which is currently Python 2).

debian: update debhelper compat Level before 9 are deprecated says debhelper 12. Upgrade to 10, which is available in Debian oldstable and old Ubuntu releases to be conservative (and since we probably don't need more).

debian: make it possible to by-pass doc build

debian: define extend-diff-ignore for dpkg-source This makes it possible to build the source package from a hg checkout (and a sdist) by having dpkg-source ignore files not distributed in sdist.

debian: use pybuild and dh_sphinxdoc Use pybuild because it's kind of standard nowadays. Use sphinxdoc debhelper to have a Depends: libjs-sphinxdoc and common files (JS/CSS) symlinked.

debian: mark 9.2.1-1 as released

obsexchange: delete dead code for old exchange protocol Dead since 79a926b557f1 (compat: drop support for older exchange protocol, 2017-10-25).

branching: merge with stable

branching: merge the stable branch with the mercurial-5.1 branch This revert all the test changes to match the expected output for mercurial 5.1.

tests: add the new "-r" bit to the usual merge hint CORE-TEST-OUTPUT-UPDATE: 8197b395710e

test-output: reinstalled test change for 5.2 This effectively reinstall: * 8345b852cd4f * e804d5a7c193 * 62b60fc1983d * 2d85de79ead8 This mean backing out the following backout changeset: * 2eab4363fc62 * c1cc5b1f813a * 015cdd3fa469 * 3ba1c9dbf462

test-compat: opening test compatibility branch for mercurial 5.1 5.2 has a release candidate.

py3: encode/decode with going through ui in rst directive mercurial's ui wants bytes, doctutils wants text.

py3: fix setup.py --version Before: $ python3 setup.py --version b'9.3.0.dev' After: $ python3 setup.py --version 9.3.0.dev

rewind: preserve date

metaedit: don't change commit date by default (issue5994) We deliberately unset devel.default-date to allow hg commands to see the real system date, that demonstrates that metaedit doesn't fall back to system date for any of these commands.

tests: simply use testlib/common.sh in test-metaedit.t

tests: turn glog shell function into an alias in test-metaedit.t Mostly because we already have an alias and because creating an alias is the usual way to customize log -G in tests.

tests: clean up test-metaedit.t Mostly just artifacts from the times when it was one big test-evolve.t. All completely unused nowadays.

help: categorizing evolve and topic commands This makes them show up under the right categories in 'hg help'. Differential Revision: https://phab.mercurial-scm.org/D6999

tests: add the new "-r" bit to the usual merge hint CORE-TEST-OUTPUT-UPDATE: 8197b395710e

branching: merge back into default

pick: don't create any successors when there were no changes (issue6093) For example, when a changeset that user is trying to pick was already grafted or rebased (and no obsmarkers were created), pick will naturally say that there's no changes to commit and will not create the new commit. In that case it should not mark any changeset as a successor of the picked changeset, because the actual file changes were already there before picking. Technically, pick could (and did before this patch) mark the wdir commit as a successor of picked changeset (may be useful in the most trivial cases when e.g. wdir is a graft of the required change), but there are cases when the picked change is introduced in an ancestor of wdir, or even in multiple ancestors piece by piece. Pick definitely shouldn't be trying to guess something this complicated, so with this patch it always marks the picked change as pruned if it gave no changes to commit.

packaging: mark as development version This avoid confusion.

Added tag 9.2.1 for changeset d989bab720e5

test-compat: merge mercurial-4.6 into mercurial-4.5

test-compat: merge mercurial-4.7 into mercurial-4.6

test-compat: merge mercurial-4.8 into mercurial-4.7

test-compat: merge mercurial-4.9 into mercurial-4.8

test-compat: merge mercurial-5.0 into mercurial-4.9

test-compat: merge stable into mercurial-5.0

packaging: prepare version 9.2.1

packaging: update changelog

manifest: exclude the gitlab file (oops)

branching: merge with stable

py3: return unicode from setup.py's get_version py3 expects the version number for eggs to be unicode, so despite 9.2.0 being the first evolve release with beta py3 support it isn't currently pip installable since it dies with: File "*/setuptools/command/egg_info.py", line *, in tagged_version return safe_version(version + self.vtags) TypeError: can't concat str to bytes The `setup.py install` test added in a previous commit should cover this since it died in a different but similar way before.

py3: remove smartquotes from README They break running setup.py with py3 but only in tests, because in the test environment `locale.getpreferredencoding()` is ANSI_X3.4-1968, so the file is `open()`ed with that as the encoding. An alternative for fixing this would be to make the `open()` call with `encoding='utf-8'` under py3, which would be safe against any future non-ascii in README.

setup: make runnable from other dirs Currently it fails when run in that way for two reasons: - the description is loaded from the README file but with a path relative to the working directory - module references have the same issue, which is fixed with package_dir.

setup: add a test for running setup.py `python3 -m pip install hg-evolve==9.2.0` currently fails, despite 9.2.0 being the first beta py3 release, because of unicode issues with the version number. `setup.py install` is a proxy test for pip install since it also suffers from similar, however the test currently fails due to running setup.py from a different directory to the one it is in. Also add a test for `hg version -v` with evolve enabled since a naive first solution for the pip issue was to just change `__version__` to a `u''` string, but that busts version display in `version -v`, which isn't currently picked up by tests.

gitlab-ci: be bold and try to run the full test in them This is a basic version that should work reasonably well. The setup is a bit costly and the cleanup is not guaranteed yet.

gitlab-ci: basic test with flake8 Let us step into the future.

branching: merge back with stable version 9.2.0 have been released

branching: preserve test change on stable CORE-TEST-OUTPUT-UPDATE: cdf0e9523de1 CORE-TEST-OUTPUT-UPDATE: d7304434390f CORE-TEST-OUTPUT-UPDATE: 181ee2118a96 CORE-TEST-OUTPUT-UPDATE: 181ee2118a96

packing: mark as development version This avoid confusion when installing from source.

Added tag 9.2.0 for changeset 40795751be1c

test-compat: merge mercurial-4.6 into mercurial-4.5

test-compat: merge mercurial-4.7 into mercurial-4.6

test-compat: merge mercurial-4.8 into mercurial-4.7

test-compat: merge mercurial-4.9 into mercurial-4.8

test-compat: merge mercurial-5.0 into mercurial-4.9

test-compat: merge stable into mercurial-5.0

changelog: update for coming 9.2.0

test: backed out test change applied in 2d85de79ead8

test: backed out test change applied in 62b60fc1983d

test: backed out test change applied in e804d5a7c193

test: backed out test change applied in 8345b852cd4f

branching: merge with stable

stable-doc: note about not storing smaller range

stable-doc: small typo

stable-doc: add more advanced examples

stable-doc: add multiples example for the simple cases

test-output: oops CORE-TEST-OUTPUT-UPDATE: 181ee2118a96

test: update part count in tests An off by one error got fixed upstream. CORE-TEST-OUTPUT-UPDATE: 181ee2118a96

evolve: check that relocating makes sense in _solvedivergent() (issue5958)

tests: demonstrate content divergence causing "relocate node on top of itself"

cmdstate: introduce a "saver" contextmanager and use it in place of save() Previously, the state was only saved in some paths out of these functions. This can be problematic, if the user ctrl-c's (or `kill -9`'s) the process, or we exit out of `relocate` for anything besides the "expected" reason, we won't record that we were in the middle of an evolve. One of our users has discovered that this leaves hg in a weird state; the user did something like this: ``` $ hg evolve <something goes wrong with the merge tool, hits ctrl-c> <deals with the merge conflicts> $ hg evolve --continue abort: no interrupted evolve to continue $ hg evolve abort: uncommitted changes # Note: commands.status.verbose=True is set. $ hg status M foo # The repository is in an unfinished *update* state. # No unresolved merge conflicts # To continue: hg update ``` The user did an `hg update`, but it didn't actually do anything besides take it out of the unfinished update state (the files were still dirty in the working directory).

cmdstate: avoid setting a default argument to a mutable object (`{}`) If there's ever more than one cmdstate for the lifetime of the process, this can cause surprising behavior where the later cmdstates pick up options from the earlier ones. I've not seen any evidence this is actually causing any issues, but it's subtle enough that it should probably be fixed to help save significant debugging time later.

cmdstate: switch to new-style classes This isn't a huge issue and isn't necessary on Python3, but we're still Python2 compatible and we should be consistent (and strongly prefer new-style classes); this is the only class that is not deriving from object that I could find.

branching: merge stable into default

docs: add example for the `prune` command Giving at least one example helps clear up the syntax, especially since most options will follow a very similar pattern.

tests: add some more actions to test-issue-6028, describe what's being done This patch does two things: it explains what's happening in the test file so it's easier to understand, and also it adds checks that make sure something like swapping merge parents is not accidentally breaking anything. The primary reason to touch this test file was that it was broken by a change in core's merge.graft() that erroneously swapped merge parents. Since only evolve uses merge.graft() for merge commits and there aren't any tests in core for it, let's test it here. Plus, this test case is pretty simple and these additional checks don't make it too complicated.

topic: fix some API to make it more robust The new code can deal with changes in upstream mercurial.

rewriteutil: move allowdivergence check to foldcheck() foldcheck() calls precheck() first and then performs more fold-specific checks.

test: change to output around transaction timing CORE-TEST-OUTPUT-UPDATE: d7304434390f

branching: merge with stable There have been multiple fix on stable.

stablerange: add some data from field testing This show that in number of stable range to track stay reasonable.

stablerange: add a debugstablerangecache command The command display get some data about stable range in a repository.

stablerange: add some documentation about the general concept

stablesort: add some field data about stable sort cache

stablesort: introduce a small debugstablesortcache command This give a small insight on the cache content.

stablesort: add some documentation for stablesort This should help people to understand what is going on here.

fold: check allowdivergence before folding obsolete changesets (issue5817)

tests: demonstrate that fold doesn't care about allowdivergence config option

stack: remove unnecessary copying of rdependencies rdependencies is not modified in any way in this method, so no need to copy it.

stack: make a deep copy of `dependencies` before modifying its items The algorithm later on in this method uses .remove() to remove individual elements from items in dependencies, which before this patch modified the cached property contents. So for further use that dictionary was in the form of {1: set([])}, i.e. all sets were empty. This deep copy block could be way simpler, but the problem is that sometimes we get lists of _succs() from evolvebits.builddependencies(). Note: this happens only in topic's stack version of builddependencies() and it looks like a suboptimal way to handle multiple successors (see evolve's counterpart function). stack.builddependencies method is removed, it has served its purpose (see the previous patch).

stack: demonstrate that not reusing cached property gives different results Instead of using self._dependencies, which is a cached property, let's get fresh deps and rdeps in stack.revs method using a newly introduced stack.builddependencies method (will be removed in the next patch). This makes it easier to explain why the next patch is correct.

branching: merge with stable

changelog: add missing entry for 9af212b8565a

evolve: test that target is not orig in _solveunstable() (issue6097) `newer` is the result of obsutil.successorssets() and can be [[orig.node()]], in which case later on in this function evolve will try to rebase orig onto orig, which is not correct. So let's just check this particular case. This fix doesn't cover cases when successorssets() result contains orig.node() not at [0][0]. Such cases need tests.

tests: demonstrate an orphan changeset cause "relocate node on top of itself" See issue6097.

obslog: only indent the first chunk and chunks just after newlines (issue6175)

tests: demonstrate too many spaces in olog -p output with word-diff

rewind: add --keep flag that "doesn't modify working directory" The actual logic is more complicated than the flag description, but it's sufficiently similar to other --keep flags in action. Unlike strip (or prune), rewind always needs to modify the working directory to commit new revisions that "revive" old ones [1], see _revive_revision() (and rewriteutil.rewrite()). Because of that we don't prevent rewind from modifying wdir, but instead use hg.updaterepo() to update to the old changeset after the "revival" process is complete. Then we rebuild the dirstate based on the commit that rewind would update to without --keep. Since dirstate.rebuild() doesn't restore status of some files (added, removed, also copies and renames), we rely on cmdutil.revert(). It's a fairly crude solution and needs to be removed when implementing the missing copy tracing between oldctx and newctx (which are related only by obsolescence). [1] IOW this means that --keep doesn't allow rewinding if wdir is dirty (unlike e.g. strip).

tests: separate rewinding of merge commits, temporarily drop an error case The error case will come back in the following commit, because it organically fits there without the need of a separate working clone.

python3: add python3 beta support to the CHANGELOG

python3: mention beta Python 3 support in README

python3: add supported python versions to setup.py Mercurial technically can support Python 3.5 (although no lower, see its setup.py), but `evolve` probably won't because it represents more work for an underrepresented Python version. If you happen to *really* need evolve to work on Python 3 and you're reading this message, send an email to the mailing list, or contribute patches.

test: update output for wider cache warming CORE-TEST-OUTPUT-UPDATE: cdf0e9523de1

branching: merge with stable format source worked smoothly :-)

python3: use format-source to run byteify-strings in .py files Using the format-source extension smooth out the pain of merging after auto-formatting. This change makes all of the Evolve test suite pass under python3 and has added benefit of being 100% automated using mercurial's `byteify-strings` script version 1.0 (revision 11498aa91c036c6d70f7ac5ee5af2664a84a1130). How to benefit from the help of format-source is explained in the README.

topic: add a new random attribute (This is mostly an excuse to test the format-source setup)

python3: enforce byte prefix for vfs.open() Changeset ea8da5aa23c6e723d7f0006387a1a20eef58fc9a added raw prefix to open(), but also to vfs.open(). The latter only handles bytestring arguments.

python3: add raw prefix to sqlite isolation level

python3: add ignore block around python 2 compatibility if branch

flake8: silence F633 error

python3: add raw prefix to edge-cases kwargs-like objects

python3: add raw prefix to open()-like functions

python3: add raw prefix to all array.array() calls

python3: add raw prefix to "troubles"-related dicts The `byteify-strings.py` script cannot know that these will be used in a way that requires to use a system string without some pretty hardcore hardcoding.

python3: add raw prefix in cases harder to analyze at the token level The `byteify-strings.py` script would be a lot more complicated if it had to do backtracking and other more advanced static analysis to figure our those cases, so we have to add the raw prefix to those cases manually.

python3: add byte prefix for objects that look like kwargs but aren't The `byteify-strings.py` script has no way of knowing that those aren't acutally kwargs since it works purely at the tokenization level, so we have to add the byte prefix to their keys manually.

python3: mark all SQL queries as raw strings

python3: prefix all regex to work with python 2 and 3

pick: added support for hg abort This patch isolates abort logic for `hg pick --abort` as `abortpick()`. For independent calls via `hg abort` `hgabortpick()` is created and registered to the state detection API. Results are shown as tests.

pick: factor our the abort function This prepare the upcoming support for `hg pick` in `hg abort.

abort: added support for evolve to hg abort This patch adds support of `hg evolve --abort` to `hg abort` plan. This involves creating a `hgabortevolve()` function under `evolvecmd` which ensures abortion of evolve via `hg abort`. This function is then registered using `addunfinished()` in `__init__.py`. Results are shown as tests.

evolve: fixed lock acquire before checking state Before checking the states `repo.lock()` and `repo.wlock()` need to be acquired. This was not happening in `evolve()` earlier. This patch creates a seperate `_performevolve()` funtion which can be then called with locks acquired. This also removes the redundant lock acuquiring of `abortevolve` and `continueevolve` as lock is now taken earlier.

py3: add back a progress(0) call lost in 8664231b47ac I don't think it really matters, but it wasn't intentional, so let's just restore the old behavior.

prune: adjust 'nothing to prune' to imply user needs to specify revs to prune

rewind: working directory is the preferred term

rewind: add command synopsis

py3: make setup.py py3 compatible

branching: merge stable back into default The version has been released.

packaging: mark as development version This help to avoid confusion when installing version from source.

Added tag 9.1.0 for changeset 6f37fdad7ac1

packaging: update version number for 9.1.0 release We are about to cut a release.

changelog: add missing entry for dfd88e3fa90a

packaging: groom changelog prior to release

test-compat: merge mercurial-4.6 into mercurial-4.5

test-compat: merge mercurial-4.7 into mercurial-4.6

test-compat: merge mercurial-4.8 into mercurial-4.7

test-compat: merge mercurial-4.9 into mercurial-4.8

test-compat: merge mercurial-5.0 into mercurial-4.9

test-compat: merge stable into mercurial-5.0

branching: merge the two mercurial-5.0 heads

test-compat: reverte output change from 4764e8436b2a (hg-5.1) These change where applied in evolve's changeset 88c8ef4d703c.

test-compat: reverte output change from f802a75da585 (hg-5.1) These change where applied in evolve's changeset e2c548cc83b5.

test-compat: reverte output change from c7d236b55a3e (hg-5.1) These change where applied in evolve's changeset f162cafc5000.

branching: merge default into stable to prepare 9.1.0 Time for a new version!

branching: merge stable into default

test-compat: merge mercurial-4.6 into mercurial-4.5

test-compat: merge mercurial-4.7 into mercurial-4.6

test-compat: merge mercurial-4.8 into mercurial-4.7

test-compat: merge mercurial-4.9 into mercurial-4.8

test-compat: merge mercurial-5.0 into mercurial-4.9

test-compat: merge stable into mercurial-5.0

test-compat: opening test compatibility branch for mercurial 5.0 5.1 has a release candidate.

test-compat: close branch for mercurial-4.0 We dropped compatibility in 9.0.0

prune: fix small grammatical issues in help text

docs: update evolve-faq.rst with new prune flag and proper vocabulary Also strip trailing newlines.

prune: spell --successor flag without any unnecessary shortcuts If a user wants to spell out -s, it makes sense to allow that. Before this patch, prune would complain that --successor is not a recognized option. Obviously people don't usually need to spell --successors by hand thanks to shell completion (at least for Bash) using debugcomplete to see all available flags, so this patch doesn't bring any need for more typing. And thanks to Mercurial understanding shortened forms of command-line flags as long as they are unambiguous, the old-style `--succ` flags still work normally, and there are tests that use them. But two tests now use the full form to demonstrate that both ways work.

py3: redefine "troublecategories" in evolve as a dict We'll want to the keys to be bytes and the values to be unicode on py3. Having it defined as a dict makes that easier (instead of converting between the types with e.g. pycompat.sysbytes()). It was kind of ugly to convert between the forms by stripping '_' from the string anyway.

py3: store to __doc__ as str (unicode on py3)

py3: also catch ImportError when relative import fails Python 3 apparently raises an ImportError where Python 2 raised a ValueError.

py3: convert exceptions to bytes using pycompat.bytestr()

py3: use "%d" for formatting integers

py3: avoid "%s" for formatting None

py3: use "%f" for formatting floating point number

py3: fix progress() functions to not use "%s" with int Python3 doesn't support "%s" with int arguments (and not with None arguments either, which this code was also using).

py3: make random topic name generation consistent across py2/py3 random.choice() (and others based on random.randint()) changed between py2 and py3 without a way to get the py2 behavior. However, random.random() did not change, so we can re-implement random.choice() based on that.

py3: convert str to bytes before passing to core exception

py3: convert opts keys to bytes before passing to core APIs

evolve: further clarify when update is performed

py3: avoid comparing int and None

py3: avoid "%r" for list of byte strings, which produces b'' on py3

py3: avoid "%r" for byte string, which produces b'' on py3 Replaced by "'%s'", which I think is clearer anyway.

py3: replace str(ctx) by bytes(ctx) These are all for messages to the user and we don't want unicode for that.

py3: use inspect.signature() instead of inspect.getargspec() on py3

py3: use array.array.{to,from}bytes() on py3 array.array.{to,from}string() still exists on py3, but they're deprecated and generate warnings. I've put the compat function in compat.pt for now. We can move into a dedicated pycompat.py if we end up with a lot of py3 compat stuff.

py3: config values can be bytes, but never unicode

py3: call branchmap.items() on py3 and continue to call iteritems() on py2 Mercurial's source transformer also replaces the 'def iteritems(' in branchmap by 'def items(', so we need to call whichever version is there.

py3: switch from iteritems() to items() in the topics extension The only remaining iteritems() call is on branchmap. That will be dealt with in the next patch.

py3: filter() now returns a generator, so wrap when we need a list

py3: don't depend on map() iterating over its input map(some_generator()) in py2 returns a list, while in py3 it returns a generator, so the passed-in generator won't be called unless the returned one is.

py3: implement __bool__ in addition to __nonzero__

py3: replace iter.next() by next(iter)

py3: replace xrange() by range()

py3: read sqlite3 data as bytes The py2 and py3 docs ([1] and [2]) disagree how to get bytes output, but it seems obvious that this should be "bytes" to be compatible with both. [1] https://docs.python.org/2/library/sqlite3.html#sqlite3.Connection.text_factory [2] https://docs.python.org/3/library/sqlite3.html#sqlite3.Connection.text_factory

py3: sqlite3.connect() expects str arguments

cleanup: remove check only needed for hg versions before 4.4 ui.edit() has had the "action" argument since 6e6452bc441d (editor: use an unambiguous path suffix for editor files, 2017-08-30), which was first released in hg version 4.4. Since we support only versions higher than 4.5, we can drop this check.

split: remove an unnecessary (and confusingly typed) fallback revision `opts.get('rev') or '.'` is either a list of strings or just a string. It happened to work because `'.'[0] == '.'` on Python 2, but it won't work on Python 3 (for byte strings). The fallback value wasn't even needed (it was also set just after), so let's just remove it.

evolve: rename variable "children" to "child" where it's clearly singular

evolve: remove some unused variables

py3: back out 23323092f0a7 D6623 has now been accepted in Mercurial (commit 83666f011679), so evolve commit 23323092f0a7 (py3: convert _origdoc to sysstr to match __doc__, 2019-07-09) is not longer needed.

branching: merge with stable

touch: fix the inconsistent behavior of divergence catching logic (issue6107) When touching a node, the way we check if it can lead to divergence is we look at the successors sets of the rev being touched. And if there is successor revs exists (excluding the case when that successor set is (A,) for rev A) that means there will be divergence and we warn the user. This works fine but there is still a case (which is not covered by looking at successor sets) which can lead to divergence. That case is: when there is already a revision exists which is divergent to the revision being touched. And performing the touch would revive that "dead" divergence. (Dead because one of the revision is obsolete which is the one we are touching) And to see if there is any rev which is divergent to a particular rev we already have a function which we can use here i.e. `evolvecmd.divergentsets(repo, ctx_being_touched)` Changes in test file demonstrate the fixed behaviour.

touch: add test which shows touch can fail to warn about divergence

touch: clarify some inline documentation

tests: update output for new branch cache messsages from Mercurial This makes tests pass again after Mercurial commit c7d236b55a3e (py3: fix formatting of branchmap log messages with repo.filtername=None, 2019-07-14). CORE-TEST-OUTPUT-UPDATE: c7d236b55a3e

metaedit: allow operations on merge commits with some conditions As with fold (see the previous patch), it's allowed to metaedit a merge commit or a set of commits including merge commits (with --fold) as long as there are less than 2 parents of the set not included in the said set.

fold: allow operations on merge commits with some conditions It's possible to fold revision chains that include a single merge commit: just fold everything into the merge commit while saving its other parent (so it continues being a merge commit). It's also possible to fold revisions that include multiple merge commits, on the condition that they merge with not more than 2 external changesets (i.e. a changesets that aren't going to be folded).

rewind: make sure merge commits include files from p1 and p2 Otherwise rewinding a merge commit makes it lose all changes. This fix populates `updates` argument of rewriteutil.rewrite() with parent changesets. That argument is normally used for folding multiple changesets, but in this case it's simply used to include files from p1 and p2. Usually, rewrite() works fine using ctx.files(), but that function can return an empty list when ctx is a merge commit.

touch: make sure merge commits include files from p1 and p2 Otherwise touching a merge commit makes it lose all changes. This fix populates `updates` argument of rewriteutil.rewrite() with parent changesets. That argument is normally used for folding multiple changesets, but in this case it's simply used to include files from p1 and p2. Usually, rewrite() works fine using ctx.files(), but that function can return an empty list when ctx is a merge commit.

py3: make `import hgext3rd.evolve` work

py3: use bytes for template keyword registrations This makes `import hgext3rd.topic` work.

py3: convert _origdoc to sysstr to match __doc__ It's currently stored as bytes by core, so we need to convert it to match Python's expected type for __doc__. This patch can be dropped if D6623 gets accepted.

py3: use bytes for revset predicate registrations

py3: use bytes for wireprotocol command registration

py3: use byte strings for @command registrations

py3: switch from iteritems() to items()

py3: make metadata values be byte strings as Mercurial expects

tests: update output for shorted prompts from Mercurial This makes tests pass again after Mercurial commits f802a75da585 (patch: use a short, fixed-size message for last line of prompt (issue6158), 2019-06-20). CORE-TEST-OUTPUT-UPDATE: f802a75da585

tests: update output for shorted prompts from Mercurial This makes tests pass again after Mercurial commits 4764e8436b2a (filemerge: make last line of prompts <40 english chars (issue6158), 2019-06-20) CORE-TEST-OUTPUT-UPDATE: 4764e8436b2a

rewriteutil: allow rewriting merge commits (issue4561) This patch simply allows rewriteutil.rewrite() to work with commits with multiple parents (i.e. merges). That function is used in such commands as fold, metaedit, touch, rewind. The issue 4561 is marked as easy, the limitation is called unnecessary, no tests fail after this change. What can go wrong.

tests: show what happens when trying to hg touch a merge commit

evolve: further clarify that update is performed only when requested Text further modified by Pierre-Yves David and Anton Shestakov.

touch: let's not use util.acceptintervention() as it's not required

branching: merge with stable

evolve: use right value for branch name when finding branch heads subbranch already formatted as "branchname:topicname", again appending it with ":topicname" doesn't not make sense. It's a little bit surprising that no tests fails though.

evolve: fix confusion in branch heads checking logic when topic in play To provide some context, when topics are in play the branchmap cache we store contains the branch info of a rev as "branch:topic" format IIUC. Assuming that is right, now in present code we don't actually cover this part that "when looking for branch heads where we also have active topic we should look for branch='branch_name:topic' instead". And we get wrong branch heads as a result. This patch make sure that we pass right candidate to find branch heads using branchmap.branchheads() by overriding the localrepo.branchheads() Changes in test file reflect the fixed behavior.

topic: add tests to demonstrate topic confuses the branchhead checking logic While topics are in play, we store the branchheads (which has a topic) in "branchname:topicname" format. After digging into it I found that even in the case when we should have branch heads for "bname:tname" we get heads for "bname". The tests output reflect the confusion in branch head checking logic. Next patch will be fixing the problem.

evolve: fix the inconsistent behaviour of prune (issue6137) Let's not update to any revision when working directory parent is not related to the revision being pruned. Changes in test file demonstrate the fixed behaviour.

prune: add tests to demonstrate issue6137 Here we can see that prune updates off to the parent revision even when the pruned revision wasn't related with the working directory parent. A follow-up patch will fix this.

compat: fix `setupevolveunfinished` for upstream

prune: update to the successor of wdir also with --pair/--biject (issue6142) When prune is used with --pair flag, we can also update to the successor of working directory parent. No need to check len(sucs) or len(precs) here because there's a check for that earlier in the code (it's a requirement of biject). The tests are now demonstrate the correct behavior: when rev 14 was pruned with 12 as its successor, the bookmark that was on 14 was moved to 12. That bookmark was also activated (even before this patch).

tests: demonstrate prune --pair not moving bookmark correctly After `mkcommit n2` line the bookmark is on the correct changeset, but when we prune --pair the two newly created changesets (revs 13 and 14), the bookmark gets moved to their ancestor (rev 0). Instead, it should've moved to the last of their successors (rev 12).

oops: backed out changeset 7ac40b4ea24c Anton requested some changes on it.

compat: fix `setupevolveunfinished` for upstream

evolve: fix the code flow pattern of solving obswdir par and troubled revs Now we will go to _handlenotrouble() (which prints messages about no revs to solve) only when there is no troubled revs and working dir parent is not obsolete. This change also saves us from an issue which was about looking into the revset (smartset contains troubled revs to solve) when a rev from the revset gets hidden. This happens in the case when our wdir parent is obsolete. After resolving obswdir parent we were looking into the revset to check if there is any troubled revs to solve but we should have performed this check before performing the obswdir resolution. Changes in test file reflect this fixed behaviour.

evolve: refactor for consistent behavior of evolve when wdp is obsolete This patch make sure that when working directory parent is obsolete `hg evolve` and `hg evolve --all` don't behave differently.

evolve: backout 3027005c42c3 to reintroduce a bug for right fix This patch backout 3027005c42c3 as it was accepted by mistake while it was being "in-discussion" state.

pick: register pickstate as an unfinished state This way pickstate file will indicate that unfinished pick command needs to be dealt with (--continue or --abort) before modifying the repo. Otherwise it would be e.g. possible to commit during an interrupted pick and that's not expected.

pick: rename variable for unfinishedstates

pick: actually delete pickstate if --abort is given Makes pick to be, uh, actually aborted.

evolve: orphans that evolve into nothing don't need successors (issue5967) When continuing to solve an orphan that created no changes (i.e. clean wdir), _completeorphan() used to create an obsmarker that said that the result of that orphan evolution is the currently checked out changeset. That's not a correct obsmarker, because all of the orphan's changes were dropped and so it had no effect on the currently checked out changeset. This is an issue that has only existed when --continu'ing evolve, that's why the fix touches _completeorphan(), but not _solveunstable(). This fix is adapted from a similar "if node is None" block in _finalizerelocate().

tests: demonstrate obsmarker creation after discarding conflicting changes Continued evolve creates an incorrect obsmarker that says 2 is a successor of 1. It's incorrect because 1 was dropped as it created no changes to commit (after conflict resolution that discarded its changes). If evolve does the same thing in one go (e.g. just by using --tool :local and without subsequent need to continue) the obsmarker is correct.

pick: remove transaction on the whole command (issue6037) At its core, pick is a pretty straightforward and well-behaving command, it uses functions already in core hg, it checks that wdir is clean and that changeset to pick is not public, it checks if there happen to be merge conflicts and can be --continue'd later, etc. It is very similar to graft in core (it also uses mergemod.graft function), but it obsoletes the original changeset. However, graft does not experience this incorrect behavior from issue 6037. What happens in the test case for this issue when we pick a revision that touches both "a" and "b": mergemod.graft() takes the original changeset and tries to apply it to the wdir, which results in "b" being marked as newly added and ready to be committed, "a" updated with the new content and being marked as modified, but "a" also has conflicts. Pick correctly notices this and saves its state before asking for user intervention. So far so good. However, when the command raises InterventionRequired to print a user-facing message and exit while being wrapped in repo.transaction() context manager, the latter partially undoes what mergemod.graft() did: it unmarks "b" as added. And when user continues pick, "b" is therefore not tracked and is not included in the resulting commit. The transaction is not useful here, because it doesn't touch wdir (it's still dirty), it doesn't remove pickstate (and other commands will refuse to work until pick --abort or --continue), it just makes "b" untracked. The solution is to use repo.transaction() only to wrap code that writes data to hg store in the final stages of the command after all checks have passed and is not expected to fail on trivial cases like merge conflicts. For example, committing the picked changeset. But since pick uses repo.commit() for that, and because that function already uses a transaction, wrapping it in another transaction doesn't make sense.

tests: demonstrate hg pick forgetting files after conflicts This test currently passes to show that pick is behaving incorrectly.

packaging: follow hg's supported python version (>= 2.7) "Mercurial 4.3 and newer require Python 2.7." (From https://www.mercurial-scm.org/wiki/SupportedPythonVersions) Also add X- prefix, because that's the correct form, apparently. This line can also be removed in future, since "When Debian supported multiple Python versions, X-Python-Version was used, but it is obsolete now as no supported Debian release supports anything other than python2.7." (From https://wiki.debian.org/Python/LibraryStyleGuide) That page also mentions "X-Python3-Version".

packaging: require hg 4.5 also for usage, not just for building

packaging: require mercurial >= 4.5 Otherwise building the doc package fails with: (third party extension evolve requires version 4.5 or newer of Mercurial; disabling) Exception occurred: File "/usr/lib/python2.7/dist-packages/mercurial/help.py", line 624, in help_ raise error.Abort(msg, hint=hint) Abort: no such help topic: evolve

evolve: clarify why returning by adding inline doc

evolve: move a code block to have right value in has_some_val Because of this we were having wrong value of has_some_val and had some buggy behavior which is being fixed by this patch. Fixed behavior is reflected by the changes in test file.

topic: add tests which demonstrate topicset failure of FilteredRepoLookupError When topics are used, it fails to find hidden revs mentioned in a revset as we are not using unfiltered view of repo. Next patch will fix it.

pick: reduce configoverride() scope Merge tool is only needed for merge.graft() (it's what graft in core hg does), so let's make the scope of the ui.configoverride() narrower.

evolve: correct action verb in a message

evolve: internationalize a message This exact message was already wrapped in _() in the same file, just not here.

evolvecmd: the proper way to deal with conflicts is to resolve them And it's worth making the suggestion an actual hint.

test-compat: merge mercurial-4.5 into mercurial-4.4

test-compat: merge mercurial-4.6 into mercurial-4.5

test-compat: merge mercurial-4.7 into mercurial-4.6

test-compat: merge mercurial-4.8 into mercurial-4.7

test-compat: merge mercurial-4.9 into mercurial-4.8

test-compat: merge stable into mercurial-4.9

branching: merge with 9.0.0

branching: merge back with stable

packaging: mark as development versions This help to distinct official release from in progress work.

Added tag 9.0.0 for changeset 756db65030c6

packaging: prepare release 9.0.0

doc: clarify the status of configuration of the obshashrange protocol

changelog: add various missing bits

templatekw: keep compatibility with Mercurial 4.5 This is simple enough to do.

test: adjust output to stable branch We are about to make a release.

branching: merge with stable

templates: don't alias keywords directly Putting the same function twice in the registry results in duplicate doc strings and therefore confusing "hg help template" output.

stack: remove 'topic.' prefix from colors/labels Stack is related to topics, sure, but it is also good enough to be recognized on its own.

stack: handle hash sizes when --debug flag is provided Since showstack() now uses fm.hexfunc() for node hashes, which depends on ui.debugflag, we should handle situations when hashes are full-sized as well.

stack: always provide (full) node hash to non-default --template

stack: remove unnecessary prefix from stack output with non-default --template "index" template keyword already exists (the current iteration of the loop), so "stack_index" it is. It follows the same convention as other template keywords, such as "files_added", "line_number", etc.

stack: provide context to formatter with non-default --template This allows using template keywords that we don't explicitly provide to the formatter, e.g. rev, branch and topic.

stack: leverage labelsgen() to produce all needed labels for fm.write()

stack: check if stack is empty more pythonically

stack: implement __bool__ and __nonzero__

stack: get stack data directly from stack and remove stackdata() stackdata function began its life in 137f8b04901e as a proto-stack: it computed stack revs on its own and only had one property to return, "changesetcount". Later it started to prepare and return more properties, but since b933a8068c17 it was computing revs using a getstack function. And then finally in 17749d9d3968 it started to rely on stack class entirely. It was a good function, but now, when all the logic it provided was factored into stack class, I'd say it's finally time for it to be put to rest.

stack: use stack._revs instead of stack.revs[1:] in external children revset The revset in question excludes all revs that are part of the stack. Using stack.revs[1:] works (rev #0 is stack base, which is not a part of the stack), but using stack._revs is technically more correct, because this variable is specifically designed to hold only revisions that are part of the stack.

test: update output to match the parent changesets This amend was forgotten.

topic: add a simple option to reject publishing The option is pretty basic but it can be used as base to build larger feature. The main target for going in this direction is to be able to distinct between user that are "simple contributors" pushing topic for review and the "maintainers" or "automation" that can publish changesets.

compat: adjust `wrapadd` for upstream Mercurial core updated the API in f385ba70e4af.

debian: override default value for SPHINXBUILD in docs/makefile This is the recommended Debian approach. As suggested by Debian Developer Stephen Kitt, use the approach recommended by Debian for building Sphinx documentation. See https://wiki.debian.org/Python/LibraryStyleGuide#Sphinx_documentation Also belated credit to Zash on the #mercurial channel on the Freenode IRC network, who suggested the Make variable approach in the first place.

obshashtree: move obshashtree in its own module The code no longer serve a core purpose. We just keep it because the command might be useful. We move it in a dedicated module so that it does not get in the way of other work.

obsdiscovery: drop `obshash` discovery protocol (issue6136) The protocol has been superseeded by stablerange for a long time. It is untested and more and more buggy. Since this is deprecated experimental code in an experimental code, we drop it. We keep the underlying computation and debug command around for now. They might still be useful to looks at repositories

cmdrewrite: use context manager for some locks and transactions These were the trivial cases where I didn't even need to extend the scope of a transaction or change indentation to fix it.

evolve: mention that --all is default, in list of options

touch: use util.acceptintervention() for closing the transaction It will close the transaction on InterventionRequired.

touch: use context manager for locks

touch: extract the logic of touching rev's to its own function This refactoring will also help us in using the context manager for locks in next patches and also help reducing the nested depth.

changelog: mention user merging in the changelog

evolve: consider using three way merge to get the user for div resolution This patch adds the logic to merge the users from two divergent csets considering the base (i.e three way merge). The case when all the three are different, we concatenate the two authors of divergent csets.

evolve: add tests for the case when div csets has different users

branching: merge with stable

evolve: move status msg to verbose mode in content-divergence resolution As suggested by Pierre-Yves, lets move these too verbose message for the user to verbose mode to decrease some noise.

debian: Override default value for SPHINXBUILD in docs/makefile Sphinx now defaults to Python 3 in Debian Buster, so we need to explicitly select the Python 2 version of sphinx-build for building docs.

docs: add SPHINXBUILD make variable This defaults to sphinx-build. The current use case is for the Evolve Debian package build.

topic: add test to increase code coverage in case of multiple topics This patch adds a test which cover the part that when we have one topic on top of other topic, this make sure that when evolving it's boundary are the current active topic (i.e hg stack)

changelog: --no-update is the default, recommend --update instead

topic: drop support for accessing csets in branch stack using bxx (issue6119) When topic extension is enabled and we have some cset whose hash is `b1234`, topic extension thinks that we are accessing 1234 cset in current branch stack. However that's not the case generally. Also I am not sure many people use this bxxx thing. Since we have a generic sxxx way to access csets, let's drop support for accessing csets using bxx which leads to bad behavior. Looking at the tests, we don't show bxxx in hg stack output anymore. I update the test to use sxxx instead of bxxxx.

legacy: drop the check for `obsolete._enabled` This looks like an ancient version check, and presumably `minimumhgversion` will do the same thing.

docs: drop references to the old temporary commit that was created with amend The sharing.rst page also mentions amend, but the diagrams aren't showing, so I'm not sure if they're in some other repo and needing to be updated.

templatekw: add `instabilities` alias for `troubles` Per https://www.mercurial-scm.org/wiki/CEDVocabulary

revset: switch internal uses and tests to `predecessors` from legacy name

revset: add `predecessor` aliases for `precursors` and `allprecursors` Per https://www.mercurial-scm.org/wiki/CEDVocabulary

revset: add `unstable` alias for `troubled` Per https://www.mercurial-scm.org/wiki/CEDVocabulary. The old name is still available (but undocumented) for compatibility. `Orphan` was renamed from `unstable` in core in 4.4, so this seems safe to do now.

docs: change `bumped` references to `phase-divergent` Per https://www.mercurial-scm.org/wiki/CEDVocabulary

docs: change `divergent` references to `content-divergent` Per https://www.mercurial-scm.org/wiki/CEDVocabulary

docs: change `troubled` references to `unstable` Per https://www.mercurial-scm.org/wiki/CEDVocabulary

docs: change `unstable` references to `orphan` Per https://www.mercurial-scm.org/wiki/CEDVocabulary

doc: correct a typo

docs: change `troubles` references to `instability` Per https://www.mercurial-scm.org/wiki/CEDVocabulary. There are a couple instances of 'troublesome' which probably need a word, as deriviatives of 'instability' didn't really fit. At least some of these are in the unlinked obs-terms.rst page.

docs: change `precursors` references to `predecessors` Per https://www.mercurial-scm.org/wiki/CEDVocabulary

docs: import figure diagrams with inkscape 0.92 No changes to the content here. This simply accepts the default option ("This file contains digital artwork for screen display") on the prompt when first opened, which is trying to upgrade from 90DPI to 96DPI.

messages: standardize on "working copy is now at" including "is" It seemed that we mostly used "is", but `hg next` and `hg prune` could print it without the "is".

evolve: move more of the progress-related variables together

evolve: delete dead calculation of number of troubled revisions The "count" variable is recalculated in the regular (no --continue) code path and it isn't used anywhere else (it used to be set to 1 in the --continue code path, but that now has its own progress counting).

evolve: drop nested locks and transactions All callers of _solveone() now take the locks and start the transactions, so there's no need to do that anymore.

next: start transaction before calling _solveone() All other callers do this, and I'm about to make _solveone() not create a transaction.

evolve: use single transaction also when continuing

evolve: run in a single transaction This speeds up `hg evolve --all` of a stack of 24 commits in the hg repo from 11.5s to 3.7s (3x). As can be seen in the tests, it also avoid some warnings about transiently unstable commits.

evolve: extract function for solving one revision, including merges Will make the next patch simpler.

evolve: mention that --all is the default behavior now

evolve: mention that not all successful operations currently update wdir

evolve: add progress support for --continue The progress starts where it left off when the previous command ran into merge conflicts.

evolve: reduce scope of progress-related variables

evolve: move progress-clearing out of _cleanup() The progress is only used with --all or --rev, so there's no need to clean it in any other case. It's therefore easier to clean it specifically in that case.

evolve: stop passing no-op "progresscb" into continueevolve() The "progresscb" doesn't do anything in the --continue case, so there's no need to pass it into continueevolve(). This lets us remove the --no-all that was added to the test as a workaround.

evolve: _solveunstable() update progress only once There's no need to draw it, then possibly write text over it (with --verbose), and then draw it again.

evolve: don't update progress just before clearing it _cleanup() will clear the progress, so there's little reason to update it just before (except for progress.debug=yes).

evolve: clean up progress bar also when using -r It looks like 1fe3da0b4601 (evolve: add --rev option to the evolve command, 2015-05-05) forgot to update the "showprogress" variable.

tests: add some basic testing of progress

evolve: increment progress *after* a whole merge commit is done The "re-stabilize" step was using the progress that was supposed to be for the next revision.

evolve: use util.acceptintervention() for closing transactions util.acceptintervention() will close the transaction on InterventionRequired.

evolve: use context manager for transactions

evolve: use consistent message and just re-raise InterventionRequired

evolve: use standard InterventionRequired instead of MergeFailure

evolve: don't use exception for local flow control The LocalMergeFailure class was added in 3f91654713dd (obsolete Move merge failure handling into stabilize code, 2012-08-20). I think the "if compat.hasconflict(r)" check was added later. Now that we have that check, we should use that for flow control instead. Note that this means that any unexpected exception from _relocatecommit() will now just raise (and roll back the transaction). I think that's an improvement.

evolve: reduce indentation with an early return statement

evolve: remove a useless return statement at end of function

test: move a test to an appropriate test file This patch introduce a new test file test-evolve-orphan-corner-cases.t for tests which covers corner cases.

test: improve the title of a test

test: remove duplicated test We have the test in test-evolve-orphan-split.t which is covering the same case this test does. Also this test states that evolve shows some error in split case, but now this is not the case we update to the top of splitted csets.

evolve: warn user for the metadata being lost in public divergence resolution This patch print warnings if some "extras" of a divergent changeset that is possibly important metadata which is being lost during the resolution of public divergence.

evolve: show a status message when merging leads to public cset I think it would be fine to tell the user that merging the two divergent csets while resolving public divergence resulted into the public cset itself. If you think we don't need to tell the user, then we can include this in debug-mode for debugging purposes at least.

test: use a shorter test name This is still long but easier to read.

stack: rename troubledcount to unstablecount

evolve: use --all by default (BC) allopt defaults to None to avoid touching _checkevolveopts(). If it were True by default, that function would always act like the flag was provided by user, and so using --abort, --stop, --continue or --rev on their own would never work (hg evolve will complain that you cannot specify both --rev and --all). A notable change in tests is "no troubled changesets" line that gets printed when using `hg evolve` to update to the evolved successor of working directory parent, but there were no actual instabilities.

tests: add --rev to hg evolve to reduce test changes for the next patch

tests: add --no-all to hg evolve to reduce test changes

evolve: don't update after instability resolution by default (BC)

tests: add --update to hg evolve to reduce test changes for the next patch

tests: don't create a nested repo for no reason

branching: merge with stable VErsion 8.5.0 got released

Added tag 8.5.1 for changeset 05c9dcf5512e

packaging: prepare version 8.5.1

test-compat: merge mercurial-4.5 into mercurial-4.4

test-compat: merge mercurial-4.6 into mercurial-4.5

test-compat: merge mercurial-4.7 into mercurial-4.6

test-compat: merge mercurial-4.8 into mercurial-4.7

test-compat: merge mercurial-4.9 into mercurial-4.8

test-compat: merge stable into mercurial-4.9

evolve: fix progress display with hg<4.7 Since d1aab9d82f5b (evolve: adapt for deprecated ui.progress(), 2019-01-14), the "item", "units" and "total" are all set to default values. The last one is especially bad since it results in a "spinner" instead of a progress bar.

packaging: mark extensions as tested with 5.0

branching: merge with stable

test-compat: merge mercurial-4.5 into mercurial-4.4

test-compat: merge mercurial-4.6 into mercurial-4.5

test-compat: merge mercurial-4.7 into mercurial-4.6

test-compat: merge mercurial-4.8 into mercurial-4.7

evolve: use merge.update() for resolving phase divergence Iterating over the manifest when tree manifests and narrowness is in play produces entries for paths outside the narrowspec that represent trees. For example, if the tests/ directory of the hg repo was not in the narrowspec (and the hg repo was using tree manifests, which it doesn't), then there would be a "tests/" entry in the manifest. The merge code deals with some of these cases. For example, it's valid to do a merge if only the local side changes directories outside the narrowspec. That allows rebasing a local commit onto a public commit that had changes to the excluded paths to work. However, _resolvephasedivergent() was iterating of the manifests, which resulted in crashes for some of our users when they tried to resolve phase-divergent commits (actually content-divergent commits that became phase-divergent after the intermediate rebase). We can fix that by relying on merge.update(), since that already handles this case. [This re-install a changeset backed out for compatibility reason]

test-compat: merge mercurial-4.9 into mercurial-4.8

compat: drop support for Mercurial 4.4

test-compat: merge stable into mercurial-4.9

compat: backed out changeset cfcb7eedc666 That changesets breaks 4.4 compat. We will reinstall it for the next version.

test-compat: adapt test output to 4.4

test-compat: merge mercurial-4.5 into mercurial-4.4

test-compat: merge mercurial-4.6 into mercurial-4.5

test-compat: merge mercurial-4.7 into mercurial-4.6

test-compat: merge mercurial-4.8 into mercurial-4.7

test-compat: merge mercurial-4.9 into mercurial-4.8

test-compat: merge stable into mercurial-4.9

compat: fix a typo in compat patch

changelog: mention extensions isolation (issue6121)

topic: only wrap wireprotocaps for repo with topic This helps repository with and without topic to coexist in the same process.

topic: only wrap _pushb2phases for repo with topic This helps repository with and without topic to coexist in the same process.

topic: only wrap handlecheckheads for repo with topic This helps repository with and without topic to coexist in the same process.

topic: only wrap wireprotobranchmap for repo with topic This helps repository with and without topic to coexist in the same process.

topic: only wrap _headssummary for repo with topic This helps repository with and without topic to coexist in the same process.

topic: only wrap desthistedit for repo with topic This helps repository with and without topic to coexist in the same process.

topic: only wrap _destupdatetopic for repo with topic This helps repository with and without topic to coexist in the same process.

topic: only wrap _destmergebranch for repo with topic This helps repository with and without topic to coexist in the same process.

topic: only wrap gettopicrepo for repo with topic This helps repository with and without topic to coexist in the same process.

topic: only wrap mergeupdate for repo with topic This helps repository with and without topic to coexist in the same process.

topic: only wrap committext for repo with topic This helps repository with and without topic to coexist in the same process.

topic: only affect `hg commit` behavior for repo with topic This helps repository with and without topic to coexist in the same process.

topic: only wrap workingctx.__init__ for repo with topic This helps repository with and without topic to coexist in the same process.

topic: introduce a `hastopicext(repo)` function This function check if a repository has the extension enabled or not.

tests: consolidate the public-content-divergent test cases This commit move the public-content-divergent tests in dedicated test files.

evolve: improve inline documentation for the public divergence resolution

cleanup: remove a duplicated line

changelog: mention topic compatibility

branching: merge stable back into default

tescompat: revert test change for mercurial-4.9 We should still test against mercurial-4.9 expected output.

branching: merge 8.5.0 expected output in stable Upstream stable is now for mercurial 5.0

testcompat: open a branch dedicated to mercurial 4.9 Upstream merged its default branch into the stable one to prepare for Mercurial 5.0

topic: add compatibility for writing copy metadata in changelog.add() As seen in hg 0e41f40b01cc.

serverminitopic: add compatibility for branchcache that now uses self._entries A copy of 9b0cde5efbc9.

branching: merge stable into default

packaging: mark version as development version Thsi help to reduce confusion for people using evolve from source

Added tag 8.5.0 for changeset 33c617626fd9

packaging: prepare version 8.5.0

test-compat: merge mercurial-4.5 into mercurial-4.4

branching: merge stable back into default

test-compat: merge mercurial-4.6 into mercurial-4.5

test-compat: merge mercurial-4.7 into mercurial-4.6

test-compat: merge mercurial-4.8 into mercurial-4.7

test-compat: merge stable into mercurial-4.8

changelog: merge 8.4.1 and 8.5.1 entries

branching: merge stable into default

branching: merge default change into stable

branching: merge default branch in stable to prepare 8.5.0 release The release is not fully ready, but the merging is non-trivial.

uncommit: abort if an explicitly given file cannot be uncommitted (BC) This corresponds to f4147ca63d39 in the core uncommit extension.

evolve: store --update flag state in evolvestate file Part of 9c522bdfc846 that wasn't yet accepted.

state: implement cmdstate.__contains__()

changelog: mention Martin work on phase-divergence

test: revert update from 5.0 record logic This revert the test changes from 90f94231db5d.

tests: remove note about already implemented --confirm with --continue 4544067b831b made --confirm work with --continue, but didn't update/remove this comment.

evolve: use merge.update() for resolving phase divergence Iterating over the manifest when tree manifests and narrowness is in play produces entries for paths outside the narrowspec that represent trees. For example, if the tests/ directory of the hg repo was not in the narrowspec (and the hg repo was using tree manifests, which it doesn't), then there would be a "tests/" entry in the manifest. The merge code deals with some of these cases. For example, it's valid to do a merge if only the local side changes directories outside the narrowspec. That allows rebasing a local commit onto a public commit that had changes to the excluded paths to work. However, _resolvephasedivergent() was iterating of the manifests, which resulted in crashes for some of our users when they tried to resolve phase-divergent commits (actually content-divergent commits that became phase-divergent after the intermediate rebase). We can fix that by relying on merge.update(), since that already handles this case.

evolve: compat patch for recordfilter change in mercurial This patch fix the broken things because of upstream changes in recordfilter() which is being used to select the hunks interactively. It fixes the test-uncommit-interactive.t by adding the compat layer. But for test-split.t I had to fix the tests manually. To make it more clear: splitting broke at evolve side because after that upstream change now interactive mode doesn't prompt "examine change to foo" if foo is mentioned explicitly using cli; and directly jumps to hunks selection prompt (well, only if there is any changes at hunks level) And the main issue is when file which is explicitly mentioned has no changes at hunk level (for e.g copy, rename, mode change, empty new file), because in that case you don't have any control on selection of that file and it would be included automatically in first cycle of interactive selection. And this "no changes at hunks level" was the reason for test-split.t breakage as now it didn't prompt for those files which are passed on cli. To fix this I have included some content in those files to make sure that tests still demonstrate the same behaviour as they were doing before breakage. Also, I replaced some "n" with "s" as it make more sense to skip all the changes to that file in one go instead of hitting "n" multiple times (if there were multiple hunks)

test: add file cancelation scenario for phase-divergence This improve the test coverage for corner cases.