filemerge: use non-minimal conflict marker regions (BC) As extensively detailed by Pierre-Yves[1], simplemerge's minimal markers can result in hopeless confusion for many common merges. As it happens, we accidentally inherited this behavior when we borrowed simplemerge from bzr; it is not the behavior used by RCS's merge(1), Since merge(1) (and not bzr) is what we aim to emulate when emulating RCS's merge markers, we simply turn this feature off. This brings us in line with the behavior of CVS, SVN, and Git as a bonus. (NB: using conflict markers with Mercurial is discouraged.) [1] http://markmail.org/message/wj5mh3lc46czlvld convert glob tessa

test: use more elaborated content in ``test-conflict.t`` We are going to introduce a setting to control the "minimisation" feature of ``internal:merge``. So we need more interesting conflicting content. We change the content in an independent changeset to make sure the coming code change leave the output unchanged.

run-tests: make --view work again

filemerge: use 'basic' as the default of '[ui] mergemarkers' for safety Before this patch, 'detailed' is used as the default of '[ui] mergemarkers'. This embeds non-ASCII characters in tags, branches, bookmarks, author and/or commit descriptions into merged files in the encoding specified by '--encoding' global option, 'HGENCODING' or other locale setting environment variables. But, if files to be merged use another encoding, this behavior breaks consistency of encoding in merged files. For example, ISO-2022-JP or EUC-JP are sometimes used as the file encoding for Japanese characters, because of historical and/or environmental reasons, even though UTF-8 or Shift-JIS are ordinarily used as the terminal encoding. This can't be resolved automatically, because Mercurial doesn't aware encoding of managed files. This patch uses 'basic' as the default of '[ui] mergemarkers' to avoid embedding encoding sensitive characters for safety. This patch puts '[ui] mergemarkers = detailed' into default hgrc file for tests, to reduce changes for tests in this patch.

largefiles: avoid unnecessary creation of .hg/largefiles when opening lfdirstate Previously, the directory '.hg/largefiles' would always be created if it didn't exist when the lfdirstate was opened. If there were no standin files, no dirstate file would be created in the directory. The end result was that enabling the largefiles extension globally, but not explicitly adding a largefile would result in the repository eventually sprouting this directory. Creation of this directory effectively changes readonly operations like summary and status into operations that require write access. Without write access, commands that would succeed without the extension loaded would abort with a surprising error when the extension is loaded, but not actively used: $ hg sum -R /tmp/thg --config extensions.largefiles= parent: 16541:00dc703d5aed repowidget: specify incoming bundle by plain file path to avoid url parsing branch: default abort: Permission denied: '/tmp/thg/.hg/largefiles' This change is simpler than changing the callers of openlfdirstate() to use the 'create' parameter that was introduced in ae57920ac188, and probably how that should have been implemented in the first place.

run-tests: write out scripts in binary mode Caught because Python 3 refuses to write bytes to a non-binary fd.

match: use util.re.escape instead of re.escape For a pathological .hgignore with over 2500 glob lines and over 200000 calls to re.escape, and with re2 available, this speeds up parsing the .hgignore from 0.75 seconds to 0.20 seconds. This causes e.g. 'hg status' with hgwatchman enabled to go from 1.02 seconds to 0.47 seconds.

util.re: add an escape method The escape method in at least one of the modules called 're2' is in C. This means it is significantly faster than the Python code written in 're'. An upcoming patch will have benchmarks.

util.re: move check for re2 into a separate method We're going to use the same check for another method in an upcoming patch.

util: remove no longer used compilere