py3: use pycompat.byteskwargs to converts kwargs to bytes baseformatter._item must contain both keys and values in bytes. So to make sure that, we convert the opts back to bytes.

py3: make adefaults keys str to be compatible with getattr getattr passes a str value of the attribute to be looked and keys in adefaults dict are bytes which resulted in AttributeError. This patch abuses r'' to make the keys str.

py3: abuse r'' to access keys in keyword arguments

py3: use pycompat.bytechr instead of chr

py3: use %d to format integers into bytestrings

py3: use pycompat.bytestr instead of bytes

py3: slice over bytes to prevent getting ascii values

py3: use encoding.unitolocal instead of .encode(encoding.encoding)

rebase: use matcher to optimize manifestmerge The old merge code would call manifestmerge and calculate the complete diff between the source to the destination. In many cases, like rebase, the vast majority of differences between the source and destination are irrelevant because they are differences between the destination and the common ancestor only, and therefore don't affect the merge. Since most actions are 'keep', all the effort to compute them is wasted. Instead, let's compute the difference between the source and the common ancestor and only perform the diff of those files against the merge destination. When using treemanifest, this lets us avoid loading almost the entire tree when rebasing from a very old ancestor. This speeds up rebase of an old stack of 27 commits by 20x. In mozilla-central, without treemanifest, when rebasing a commit from default~100000 to default, this speeds up the manifestmerge step from 2.6s to 1.2s. However, the additional diff adds an overhead to all manifestmerge calls, especially for flat manifests. When rebasing a commit from default~1 to default it appears to add 100ms in mozilla-central. While we could put this optimization behind a flag, I think the fact that it makes merge O(number of changes being applied) instead of O(number of changes between X and Y) justifies it.

changegroup: delete unused 'bundlecaps' argument (API)

localrepo: reuse exchange.bundle2requested() It seems like localrepo.getbundle() is trying to do the same thing, so let's just call the method. That way we get the same condition as there (matching any "HG2" prefix, not only "HG20").

py3: use raw strings while accessing class.__dict__ The keys of class.__dict__ are unicodes on Python 3.

py3: handle opts correctly for `hg add` opts in add command were passed again to cmdutil.add() as kwargs so we need to convert them again to str. Intstead we convert them to bytes when passing scmutil.match(). Opts handling is also corrected for all the functions which are called from cmdutil.add().

py3: handle opts correctly for rollback dryrun and force are just check for None, the value is not used. So its better to leave opts as unicodes as that wont harm us.

py3: handle opts correctly for unbundle There is just a check whether the value is None or not. So even having optupdate as unicodes won't harm us.

py3: convert opts to bytes in cmdutil.dorecord() commands.commit() calls cmdutil.dorecord() where opts are passed as unicodes being keyword arguments. This patch converts them back to bytes as they are required.

py3: make sure opts are passed and used correctly in help command opts are converted back to bytes in help.help_() where they are used. Before that it's ensured that we have a bytes value for keep variable.

py3: handle opts uniformly in commands.py Since keyword arguments can't be bytes on Python 3, we converted then to unicodes before passing into different command functions. We need to adopt a certain pattern to convert opts back to bytes. Following are some of the functions which are called from inside these command functions and should always be feeded bytes to follow the right behaviour. ui.fomattter() scmutil.match() patch.diffallopts() hg.peer() cmdutil.{show_changeset|copy|graphrevs|checkunsupportedflag} server.{createservice|runservice} There are few commands which are left out where opts is again passed to a function as keyword arguments or converting opts back to bytes is kind of not necessary. Those are cat, revert, help, unbundle and rollback. Following patches will deal with them. This patch apart from these five commands, convert opts back to bytes for rest of the commands. This fixes a lot of things which are hidden like --git works now. Similarly more flags of commands which run on Python 3 currently get fixed.

merge with stable

webcommands: use fctx.isbinary

annotate: use fctx.isbinary

fileset: use fctx.isbinary instead of util.binary(fctx.data()) filectx provides "isbinary" to test if the data is binary. Let's use it. This enables other filectx implementations (like LFS) to override the isbinary test.

internals: document that "branches" is a legacy wire command Modern clients use a different discovery mechanism.

match: make subinclude construction lazy The matcher subinclude functionality allows us to have .hgignore files that include subdirectory hgignore files. Today it parses the entire repo at once, even if we only need to test a file in one subdirectory. This patch makes the subinclude tree creation lazy, which speeds up matcher creation significantly in large repos with very large trees of ignore patterns.

bisect: allow resetting with unfinished graft/rebase/etc "hg bisect --reset" just deletes the state file (it doesn't move back to the starting point like rebase does); it can not conflict with an ongoing rebase etc. checkunfinished() has this documentation: It's probably good to check this right before bailifchanged(). So that's where I moved it.

py3: use %d instead of %s for integers dispatch._runcatch() always returns an integer value.

py3: make posix.getuser return a bytes

py3: replace str with bytes in isinstance()

py3: use pycompat.bytestr() instead of str() This is because str() on python 3 return unicodes

py3: alias long to int on Python 3

setup: sys.version_info always exists It is documented as existing since Python 2.0, and empirically from other OSS projects I maintain, there is no problem relying on its existance.

filelog: fix parsemeta docstring 75bb7c702317 changed the return type of filelog.parsemeta but forgot to update its docstring.

util: remove doc of long gone 'targetsize' argument Gone since fa836e050c50 (chunkbuffer: removed unused method and arg, 2007-10-11).

cleanup: drop the deprecated 'localrepo._link' method This was deprecated in favor of 'localrepo.wvfs.islink'. We can now drop it for the future 4.3.

cleanup: drop the deprecated 'localrepo.wfile' method This was deprecated in favor of 'localrepo.wvfs.join'. We can now drop it for the future 4.3.

cleanup: drop the deprecated 'localrepo.join' method This was deprecated in favor of 'localrepo.vfs.join'. We can now drop it for the future 4.3.

cleanup: drop the deprecated 'localrepo.tag' method This was deprecated in favor of 'mercurial.tags.tag'. We can now drop it for the future 4.3.

cleanup: drop the deprecated 'localrepo.opener' method This was deprecated in favor of 'localrepo.vfs'. We can now drop it for the future 4.3.

cleanup: drop the deprecated 'localrepo.wopener' method This was deprecated in favor of 'localrepo.wvfs'. We can now drop it for the future 4.3.

cleanup: drop vfs compatibility layer in scmutil All these constructors are deprecated in 4.2. We can now drop them on the default branch (future 4.3).

test-worker: exercise more about "killworkers" situation This patch adds some sleep and increases numcpus to exercise the "killworkers" situation. So race conditions could be discovered more easily, if someone changes worker.py incorrectly. Currently worker.py should be free of such issues.

test-worker: capture tracebacks more reliably The traceback test may have traceback caused by SIGTERM. Instead of grepping "Traceback", explicitly grep the exception we care about. This makes the test less flaky.

worker: rewrite error handling so os._exit covers all cases Previously the worker error handling is like: pid = os.fork() --+ if pid == 0: | .... | problematic .... --+ try: --+ .... | worker error handling --+ If a signal arrives when Python is executing the "problematic" lines, an external error handling (dispatch.py) will take over the control flow and it's no longer guaranteed "os._exit" is called (see 86cd09bc13ba for why it is necessary). This patch rewrites the error handling so it covers all possible code paths for a worker even during fork. Note: "os.getpid() == parentpid" is used to test if the process is parent or not intentionally, instead of checking "pid", because "pid = os.fork()" may be not atomic - it's possible that that a signal hits the worker before the assignment completes [1]. The newly added test replaces "os.fork" to exercise that extreme case. [1]: CPython compiles "pid = os.fork()" to 2 byte codes: "CALL_FUNCTION" and "STORE_FAST", so it's probably not atomic: def f(): pid = os.fork() dis.dis(f) 2 0 LOAD_GLOBAL 0 (os) 3 LOAD_ATTR 1 (fork) 6 CALL_FUNCTION 0 9 STORE_FAST 0 (pid) 12 LOAD_CONST 0 (None) 15 RETURN_VALUE

dispatch: take over SignalInterrupt handling from scmutil dispatch handles KeyboardInterrupt already. This makes the code more consistent, and makes worker not print "killed!" if it receives SIGTERM in most cases (in rare cases there is still "killed!" printed, which will be fixed by the next patch).

merge stable into default

Added signature for changeset 26c49ed51a69

Added tag 4.2.2 for changeset 26c49ed51a69

help: cleanup grammar in the hooks section

merge with i18n

revlog: backed out changeset e9d325cfe071 We'll move this to the default branch.

i18n-pt_BR: synchronized with efebc9f52ecb

revlog: add an experimental option to mitigated delta issues (issue5480) The general delta heuristic to select a delta do not scale with the number of branch. The delta base is frequently too far away to be able to reuse a chain according to the "distance" criteria. This leads to insertion of larger delta (or even full text) that themselves push the bases for the next delta further away leading to more large deltas and full texts. This full text and frequent recomputation throw Mercurial performance in disarray. For example of a slightly large repository 280 000 files (2 150 000 versions) 430 000 changesets (10 000 topological heads) Number below compares repository with and without the distance criteria: manifest size: with: 21.4 GB without: 0.3 GB store size: with: 28.7 GB without 7.4 GB bundle last 15 00 revisions: with: 800 seconds 971 MB without: 50 seconds 73 MB unbundle time (of the last 15K revisions): with: 1150 seconds (~19 minutes) without: 35 seconds Similar issues has been observed in other repositories. Adding a new option or "feature" on stable is uncommon. However, given that this issues is making Mercurial practically unusable, I'm exceptionally targeting this patch for stable. What is actually needed is a full rework of the delta building and reading logic. However, that will be a longer process and churn not suitable for stable. In the meantime, we introduces a quick and dirty mitigation of this in the 'experimental' config space. The new option introduces a way to set the maximum amount of memory usable to store a diff in memory. This extend the ability for Mercurial to create chains without removing all safe guard regarding memory access. The option should be phased out when core has a more proper solution available. Setting the limit to '0' remove all limits, setting it to '-1' use the default limit (textsize x 4).

rebase: also test abort from pretxnclose error Different hooks will have different properties so we cover more hooks to catch further regressions.

rebase: reinforce testing around precommit hook interrupting a rebase Different hooks will have different properties so we cover more hooks to catch further regression.

rebase: provides test case for (issue5610) The 4.2 release introduces a regression regarding the behavior of rebase with some hook failures. We add the tests from the bug report from Henrik Stuart to our test base to prevent further regression on this.

rebase: backed out changeset cf8ad0e6c0e4 (issue5610) Having a single transaction for rebase means the whole transaction gets rolled back on error. To work around this a small hack has been added to detect merge conflict and commit the work done so far before exiting. This hack works because there is nothing transaction related going on during the merge phase. However, if a hook blocks the rebase to create a changeset, it is too late to commit the work done in the transaction before the problematic changeset was created. This leads to the whole rebase so far being rolled back. Losing merge resolution and other work in the process. (note: rebase state will be fully lost too). Since issue5610 is a pretty serious regression and the next stable release is a couple day away, we are taking the backout route until we can figure out something better to do.

rebase: backed out changeset 2519994d25ca In the process of fixing issue5610 in 4.2.2, we are trying to backout cf8ad0e6c0e4. This changeset is making changes that depend on cf8ad0e6c0e4, so we need to back it out first. Since issue5610 is pretty serious regression and the next stable release is a couple of days away, we are taking the backout route until we can figure out something better to do.

make: add Debian 9 (Stretch) docker target

make: templatize Debian build target a la e63dfbbdbd07

make: add Ubuntu Zesty docker targets (.deb and ppa) Zesty Zapus was released on 2017-04-13 and will be supported until 2018-01.