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.