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