profiling: cope with configwith default value handling changes Changeset 6ff6eb33f353 change 'configwith' behavior so that the default value is run through the conversion function. In parallel a new user of 'configwith' got introduced unaware of this coming behavior change. This broke profiling. We resolve the situation by having the new conversion function cope with a default value already using the right type.

py3: catch StopIteration from next() in generatorset IIUC, letting the StopIteration through would not cause any bugs, but not doing it makes the test-py3-commands.t pass. I have also diligently gone through all uses of next() in our code base. They either: * are not called from a generator * pass a default value to next() * catch StopException * work on infinite iterators * request a fixed number of items that matches the generated number * are about batching in wireproto which I didn't quite follow I'd appreciate if Augie or someone else could take a look at the wireproto batching and convince themselves that the next(batchable) calls there will not raise a StopIteration.

tests: adjust quoting to keep Windows happy with recent $PYTHON change I tried adding quotes to the $PYTHON variable, and also tried converting the path from the current 'c:/Python/python.exe' form to '/c/python/python.exe', but neither worked. I'm not sure why one of these needs '\"' around the variable and the other doesn't.

bundle2: don't use debug message "no-transaction" with transaction

py3: use pycompat.bytestr() in place of str()

py3: use r'' to access values from kwargs where keys are str These are the cases where either args is again passed as keyword argument or 1 or 2 elements are accessed. So it's better to add an r'' to prevent it converting to bytes rather than doing the conversion of args.

py3: convert keys of kwargs in template keywords functions to bytes This patch converts the args argument keys' to bytes wherever necessary as there are some places where either args is not used or using r'' is better or args is again passed as keyword arguments.

py3: make sure the commands name are bytes in test-devel-warnings.t

py3: replace str with bytes in isinstance() We were using str because on Python 2, str were bytes but now we have to use bytes. Otherwise the if conditions fails and we have weird results from commands on Python 3.

py3: catch binascii.Error raised from binascii.unhexlify Before Python 3, binsacii.unhexlify used to raise TypeError, now it raises binascii.Error.

shelve: allow unlimited shelved changes per name Previously, there is a 100 changes limit per name (bookmark or named branch). And the user will get "too many shelved changes named %s" when they are trying to shelve the 101th change. I hit that error message today. This limit was introduced by the shelve extension since the beginning. The function generating the names was called "gennames", under "getshelvename". There is another "gennames" under "backupfilename": def backupfilename(self): def gennames(base): yield base base, ext = base.rsplit('.', 1) for i in itertools.count(1): yield '%s-%d.%s' % (base, i, ext) "itertools.count" is an endless counter. Since the other "gennames" generates unlimited number of names, and the changeset introducing the limit (49d4919d21) does not say why the limit is useful. It seems safe to just remove the limit. The format "%02d" was kept intentionally so existing shelved changes won't break.

config: use the new '_unset' value for 'configsuboptions' This should let configsuboptions delegate all special processing of the default config value to the main 'config' method.

config: use the 'config' method in 'configsuboptions' There was unnecessary code duplication. It was getting in the way of the unification of the default value logic.

config: use the new '_unset' value for 'configpath' This should let 'configpath' delegate all special processing of the default config value to the main 'config' method.

config: use the new '_unset' value for 'configdate' This should let 'configdate' delegate all special processing of the default config value to the main 'config' method. The default value for date (None) is still enforced in this method if no other default were passed.

config: use the new '_unset' value for 'configlist' This should let 'configlist' delegate all special processing of the default config value to the main 'config' method. The default config value ([]) is still handled in this method.

config: use the new '_unset' value for 'configbytes' This should let 'configbytes' delegates all special processing of the default config value to the main 'config' method.

config: use the new '_unset' value for 'configint' This should let 'configint' delegates all special processing of the default config value to the main 'config' method.

config: use the new '_unset' value for 'configwith' This should let 'configwith' delegate all special processing of the default config value to the main 'config' method. This changeset introduce a small change in behavior since the default value is run through the 'convert' function. This does not seems harmful and no actual test break. This small change make the code simpler so I'm keeping it.

config: use the new '_unset' value for 'configbool' This should let 'configbool' delegate all special processing of the default config value to the main 'config' method. The default value for bool (False) is still enforced in this method if no other default were passed.

config: explicitly track the use of the standard default value We introduce a small object used to detect that no specific default value has been passed to 'ui.config'. We need this explicit special value since "None" is a valid and common default value. The end goal here is to make progress on a centralised and explicit declaration of the available config option. A first good usecase for this are "default" value. Before starting looking further down this alley we needs to rework the handling of default value in the 'ui' object to have all configxyz methods going through the same logic. This is the first changeset on this trek.

clonebundle: update hook arguments (BC) By calling applybundle() with 'clonebundles' and the url instead of calling processbundle(), the hooks will get different arguments: HG_SOURCE will be 'clonebundles' instead of 'bundle2' and HG_URL will be the url instead of 'bundle2'. This is consistent with the bundle1 behavior and seems like a bug fix, but I'm marking it BC anyway.

commands: move checkconflict to bookmarks module Again, commands.bookmark is getting too large. checkconflict already has a lot of state and putting it in the bmstore makes more sense than having it as a closure. This also allows extensions a place to override this behavior. While we're here, add a documentation string because, well, we should be documenting more of our methods.

commands: move checkformat to bookmarks module commands.bookmark has grown quite large with two closures already. Let's split this up (and in the process allow extensions to override the default behavior).

tests: tell pip not to check for a newer version pip will check to see if it's the latest version, and complain if it isn't. The --no-index flag implies the --disable-pip-version-check flag, and makes the warning (and any associated network activity) go away.

changeset_templater: backport parts map of [templates] section from formatter

formatter: add support for parts map of [templates] section Unlike a mapfile whose template is looked up by spec -> mapfile -> topic, [templates] section is global. We use :sub-section syntax to define parts per template.

changeset_templater: backport separator template from formatter As commented, this should be used with docheader and docfooter, not with header nor footer. That's one reason why no props are passed to templater when rendering a separator. (See map-cmdline.changelog to understand what the "header" is.)

formatter: add support for separator template This seems useful for writing JSON template.

formatter: add support for docheader and docfooter templates templatepartsmap() is a minimal copy of changeset_templater.__init__(). I tried to factor out a common function, but it was unnecessarily complicated.

formatter: extract helper function to render template

changeset_templater: do not enable verbosity postfix for [templates] section Since this postfix hack exists only for backward compatibility, we don't need it for new [templates] section. This isn't a BC as templates defined in [templates] section weren't loaded until recently.

changeset_templater: simplify handling of verbosity postfix

merge with stable

tests: don't touch the network when using virtualenv

tests: removed ReportedTest exception The only call site called addFailure before raising, which is exactly what the failure exception handler does. So this complexity is not needed. We have test coverage of this "server failed to start" scenario and nothing appeared to change.

tests: remove support for warned tests The previous changeset removed the last caller of addWarn(). So, we rip out that method and all the code related to tracking warned tests in the results system. There was even a comment saying we may want to fold warned tests into the "failed" state, which is what the previous changeset did.

contrib: add check-code rule to enforce non-use of `python` in tests

cleanup: use $PYTHON to run python in many more tests Spotted one of these, then wrote a check-code rule that caught them all. It will be the next change.

tests: enforce use of $PYTHON in tests

tests: use $PYTHON in #! so we always use the right Python

tests: sed away python #! in test-run-tests.t to avoid some upcoming insanity

tests: remove #! from primes.py in test-highlight.t It's about to be a source of trouble, but removing it changes a ton of test lines, so doing this change as a standalone commit.

keyword: use context manager for rollback locking

tests: remove WarnTest We would raise this if a test didn't return a result code. AFAICT this can only occur if there is a logic error in the test harness itself. I don't think it is worth the code complexity to distinguish this failure scenario from a regular test failure.

tests: remove unused IgnoreTest exception AFAICT its last use was removed in d839e4820da7.

tests: use unittest.SkipTest unittest.SkipTest was introduced in Python 2.7. We previously defined it with our own class so we could run on Python 2.6.

changegroup: delete "if True" and reflow

changegroup: let callers pass in transaction to apply() (API) I think passing in the transaction makes it a little clearer and more consistent with bundle2.

repair: create transaction for bundle1 unbundling earlier See earlier patch for motivation.

unbundle: create transaction for bundle1 unbundling earlier See earlier patch for motivation.

exchange: create transaction for bundle1 unbundling earlier changegroup.apply() currently creates a transation if there isn't already one. Having the callers of that method pass in an existing transaction seems a little cleaner. To do that, we need to make sure all callers have a transaction. Since the transaction name is used as a hook argument (HG_TXNNAME), we need to match the name from changegroup.apply().

changegroup: inline 'publishing' variable in apply()

repair: remove unnecessary locking for bookmarks The caller has already locked the repo.

repair: move check for existing transaction earlier Several benefits: * Gets close the comment describing it * Splits off unrelated comment about "backup" argument * Error checking is customarily done early * If we added an early return to the method, it would still consistently fail if there was an existing transaction (so we would find and fix that case quickly) One test needs updating with for this change, because we no longer create the backup bundle before we fail. I don't see much reason to create that backup bundle. If some command was adding content and then trying to strip it as well within the transaction, we would have a backup for the user, but the risk of that not being discovered in development seems very small.

strip: remove unncessary "del" and inline variable

repair: clarify in comment that caller must take lock, but not transaction I have checked that all callers have already taken the lock (and if they hadn't, we should have seen tests fail thanks to the 'transaction requires locking' devel warning in localrepo.transaction()).

amend: use context manager for locking

strip: use context manager for locking and transaction in stripcmd()

strip: use context manager for locking in strip()

rebase: use context manager for locking in pullrebase()

rebase: use context manager for locking in rebase()

test-http-proxy: redirect proxy stdout to /dev/null This output hasn't been getting flushed, but would alter the log if it ever grew large enough. See 23b07333a8b2.

test-logtoprocess: don't run on Windows Several bits of output were missing[1], unless the DETACHED_PROCESS flag is _not_ passed to subprocess.Popen(). The problem with that is it briefly opens and closes several cmd.exe windows on screen. Foozy also mentioned some other issues in that thread. With this, the last of the long standing Windows failures fixed, the test suite now runs cleanly (536 ran, 67 skipped) on Windows 7 x64, with python 2.7.13. \o/ [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-April/096987.html