py3: add pycompat.open and replace open() calls open() requires mode argument as unicodes on Python 3. This patch introduces pycompat.open() which is inserted to files using transformer and replaces builtins.open() calls.

localrepo: deprecate 'repo.opener' (API) The "new" 'repo.vfs' attribute have been around for almost 5 years. I think we can deprecate the old form now ;-)

statichttp: use 'repo.vfs' as the main attribute We are about to deprecate the repo.opener attribute, we prepare the static http code to be ready for this change.

clonebundle: use 'repo.vfs' instead of 'repo.opener' The later is a 5 years old form.

localrepo: deprecated 'repo.wopener' (API) The "new" 'repo.wvfs' attribute have been around for almost 5 years. I think we can deprecate the old form now ;-)

localrepo: add some comment about role of various vfs object This should make things clearer for most people.

tests: un-nest the `order` repo in test-rebase-scenario-global This wasn't hurting anything, but it's more in line with how we manage other tests.

osx: install bash and zsh completions by default The zsh location appears to be on the default $fpath for zsh. bash, on the other hand, appears to have no default location for completion scripts, so we follow the lead of Apple's Git distribution and select a semi-arbitrary place in /usr/local for the file.

util: add allowhardlinks module variable To enable extensions to enable hardlinks for certain environments, let's move the 'if False' to be an 'if allowhardlinks' and let extensions modify the allowhardlinks variable. Tests on linux ext4 pass with it set to True and to False.

merge with stable

Added signature for changeset 25703b624d27

Added tag 4.1.1 for changeset 25703b624d27

merge with i18n

i18n-pt_BR: synchronized with 7074589cf22a

i18n-ja: synchronized with 7074589cf22a

revert: remove set(mf) because it's O(manifest) The revert code had a 'set(manifest)' line in it, which has a runtime equivalent to the size of the manifest. With alternative manifest implementations, like treemanifest, this can be extra expensive. Let's rewrite it to be O(changes) instead of O(manifest size).

share: add --relative flag to store a relative path to the source Storing a relative path the source repository is useful when exporting repositories over the network or when they're located on external drives where the mountpoint isn't always fixed. Currently, Mercurial interprets paths in `.hg/shared` relative to $PWD. I suspect this is very much unintentional, and you have to manually edit `.hg/shared` in order to trigger this behaviour. However, on the off chance that someone might rely on it, I added a new capability called 'relshared'. In addition, this makes earlier versions of Mercurial fail with a graceful error. I should note that I haven't tested this patch on Windows.

minirst: support passing admonitions into findadmonitions() and parse() This will allow consumers to declare a custom list of admonitions to parse. Without this patch, custom admonitions would get removed when prunecomments() is run. We could add an argument controlling whether prunecomments() is run. However, it is better to convert the "paragraph" block to an "admonition" block so consumers don't have to parse for custom admonitions.

minirst: dynamically compile admonitions regexp Currently, parsing admonitions uses a static regular expression created from a pre-defined list of admonitions. A future patch will introduce a feature that needs to parse custom admonitions. Prepare for this by compiling the admonitions regular expression during each function invocation. Strictly speaking, there is a slight performance loss here. But we only run this code as part of displaying help text. I don't think the loss will be noticeable and I don't think we care if it were.

minirst: detect bullet lists using asterisks Previously, the "bullet" regular expression excluded the asterisk ('*') as a character denoting a bulleted list. Why I'm not sure because the asterisk seems to be the canonical bullet character in reST these days. This patch makes asterisk-prefixed lines parse as bulleted lists.

color: update the help table We also need to reference the new topic in the great old help table.

ui: remove superfluous indent in _write()

smartset: reorder initialization of baseset in more intuitive way What we want to do is to assign either _set or _list per the given data type.

config: update the Windows example config file We move from the color extensions to the 'ui.color' config.

help: use 'churn' instead of 'color' as an example extension The 'color' extensions is now deprecated.

config: suggest the 'ui.color' instead of the 'color' extension The extensions is deprecated now so we should offer the core way to handle color instead.

color: update main documentation Now that the feature no longer lives in the extension, we document it in the help of the core config. This include the new 'ui.color' option introduced in the previous changesets. As a result the color extensions can now be deprecated. This is a documentation patch only; color is still disabled by default.

pager: drop the 'color' dependant code The 'color' implementation is in core and no longer wrap '_runcommand'. We drop the extra complexity.

color: cleanup 'debugcolor' logic Now that style are carried by the 'ui' object, we no longer need complicated logic to restore the original style. We just need to copy the 'ui' and work on the copied version.

color: move 'debugcolor' into the 'debugcommands' modules This is the last bits we needed to move out of the extensions. 'hgext/color.py' now only contains logic to changes the default color behavior to 'auto'. However, more cleanups are on the way and we need to document the new config directly in core.

merge with stable

worker: flush messages written by child processes before exit I found some child outputs were lost while testing the previous patch. Since os._exit() does nothing special, we need to do that explicitly.

worker: add basic test to ensure child processes are managed well This should catch the bug fixed by "worker: ignore meaningless exit status indication returned by os.waitpid()." Before, worker.py was untested since test repositories are relatively small.

color: rename '_styles' to '_defaultstyles' for clarity This should make it clear the dict is only used for new config. Extensions should not modify it directly anyway since we have 'extraloader' logic for loading '_styles' too.

color: move 'styles' definition on the 'ui' object Same logic as for '_terminfoparams'. The content depends on the config so it should be specific to each 'ui instance.

color: pass 'ui' to 'win32print' Same logic as before,'win32print' relies on some data we will move on the 'ui' object soon, we update the API beforehand for clarity.

color: move the dict with terminfo parameters on the ui object This dictionnary is affected by the content of the config, so we should have one for each ui config. We rename the global dict to '_baseterminfoparams' to make the situation clearer.

color: add ui to effect rendering We'll carry more and more color specific data on the ui object. This will help isolating different color configuration from each other. For example repository config might configure special style that should not affect other ui object. The first step is to make sure the ui object is available were we will needs it.

color: initialize color for the localrepo ui The 'ui' object dedicated to a 'localrepo' is independent from the one available in dispatch (and 'uisetup'). In addition, it is created from the 'baseui' (apparently for good reason). As a result, we need to run the color setup on it after the local repository config is read. This was overlooked when the rest of the initialization changed but did not had impact yet because all setup is still global. We fix it before it is too late.

color: add a 'ui.color' option to control color behavior This new option control whether or not color will be used. It mirror the behavior of '--color'. I usually avoid adding new option to '[ui]' as the section is already filled with many option. However, I feel like 'color' is central enough to deserves a spot in this '[ui]' section. For now the option is not documented so it is still marked as experimental. Once it get documented and official, we should be able to deprecate the color extensions. There is more cleanup to do before that documentation is written, but we need this option early to made them. Having that option will allow for more cleanup of the initialisation process and proper separation between color configuration.

color: reinvent dictionary move the module lever dictionary declaration to a more standard (and practical indentation)

chg: deduplicate error handling of ui.system() This moves 'onerr' handling from low-level util.system() to higher level, which seems better API separation.

chg: refactor ui.system() to be partly overridden Since fd598149112b changed the signature of ui.system(), chgui.system() should have been updated. This patch factors out the util.system() call so that chg can override how a shell command is executed.

color: have the 'ui' object carry the '_colormode' directly Before this changeset, the value was carried by the class to work around limitation of the extensions initialisation. Now that the initialisation is cleanly handled in 'dispatch', we can drop this work around.

color: move triggering of the initialisation logic in core We now run the color initialisation as part of the standard dispatch. This is opening the way for multiple cleanups since we now have access to the multiple 'ui' object and we'll be able to see difference between global and local config. This cleanup will arrive in later changesets. As a side effect, the '--color' flag is now working without the extension. Since we now properly initialize color for each ui idependently, we get a warning message twice.

color: add the definition of '--color' in core If we want to be able to move the initialisation in core, we need core to be aware of that '--color' flag at all time. So we now have the definition in core. That flag is currently unprocessed without the extensions (will be fixed soon). In addition the default value for this flag in core is 'never'. Enabling the extensions change that default value to 'auto'.

color: handle 'ui.plain()' directly in mode setup If 'ui.plain()' is set we should not colorize. We move that logic into the function that determine and setup the color mode. As all other code respect the resulting mode this will be equivalent.

color: move git-subrepo support into the subrepo module Now that all ui instance carry a '_colormode' attribute, we can access and comply to it directly in the subrepo code. The actual implementation could probably be a bit smarter, but we stick close to the current one for the sake of simplicity.