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.