tests: check path separator in moves

tests: fix test-commandserver phase . output for windows

hfs+: rewrite percent-escaper (issue3918) The original code was a bit too clever and got confused by some cp949 Korean text. This rewrite bytes the bullet and manually decodes UTF-8 sequences. Adds some doctests.

merge with stable

revert: ensure that copies and renames are honored (issue3920) Previously, we restored the states of files, but not the additional information the dirstate uses to track copies and renames.

hgignore: fix regression with hgignore directory matches (issue3921) If a directory matched a regex in hgignore but the files inside the directory did not match the regex, they would appear as deleted in hg status. This change fixes them to appear normally in hg status. Removing the ignore(nf) conditional here is ok because it just means we might stat more files than we had before. My testing on a large repo shows this causes no performance regression since the only additional files being stat'd are the ones that are missing (i.e. status=!), which are generally rare.

templater: fix output instability from gsoc patches

log-style: add a log style that is default+phase (issue3436) There is a new style called phases style. Usage:: hg log --style phases Why do we need this new style - in what way is it different from or similar to existing styles? The new style is default + phases information. With the new phases feature the users exhibited their desire for a new style that could help them. Why do this need a new style - couldn't it be folded into an existing style? The default style and the new one are about the same, the difference is the phases tag. The users find both styles useful, this means that the both styles must exist.

templater: show the style list when I try to use a wrong one When someone try to use a wrong style, a list with sugestions will appear. In the test-log.t file it's a test that prove this thing.

test-nested-repo.t: touch another file inside nested repo This helped uncover a bug in a patchset I've been writing.

check-code: add more path sep glob checks

splicemap: improve error handling when source is subversion (issue2084) Implemented error handling on splicemap file when source is subversion (This checks are similar to when source is hg or git). The revision string is expected to be of svn:<uuid><path>@<number> format. the test case has been enhanced to check this format.

splicemap: improve error handling when source is git (issue2084) Implemented similar error handling that is done for hg in an earlier revision. These are: a. add checking for splicemap file format b. add checking for each revision string formats

splicemap: improve error handling when source is hg (issue2084) 1. Introduced 2 levels of error handling for splicemap files a. Check the splicemap file for rules which are same across different types of source repos. This is done through enhancing parsesplicemap function b. Check revision string formats. Each repo may have their own format. This is done usign checkrevformat function c. Implemented the above two for hg

splicemap: move parsesplicemap to convcmd.py (issue2084) parsesplicemap is only referenced from convcmd.py This move is necessary to enable other changes related to this issue

merge with stable

tests: sprinkle globs over largefiles/subrepo tests for Windows

tests: skip permissions tests in test-phases-exchange when fs lacks permissions

merge with stable

Added signature for changeset 23f785b38af3

Added tag 2.6 for changeset 23f785b38af3

bookmarks: fix bug that activated a bookmark even with -r passed If the current revision was the target revision of -r, then the bookmark would be active. Test cases have been updated accordingly.

bookmarks: resolve divergent bookmark when moving across a branch This patch resolves a single divergent bookmark if a divergent bookmark exists in the target revision and it current bookmark is not an ancestor of the target revision, else it would already be handled by the previous patch in this series. Test coverage is added.

bookmarks: resolve divergent bookmarks when moving active bookmark forward This patch resolves divergent bookmarks between the current active bookmark MARK and the new destination. This situation can arise when pulling new changesets, abandoning your current changesets actively bookmarked with MARK via strip, and then doing a bare update. The non-divergent but active bookmark MARK is then moved to a common ancestor of the new changesets and the abandoned changesets. Test coverage is added.

bookmarks: resolve divergent bookmarks when fowarding bookmark to descendant This patch is a follow-up to 56dd55da2f7d that resolves divergent bookmarks between the to-be-forwarded bookmark MARK and the new descendant. This situation can happen when pulling new changesets, updating to the divergent bookmark, abandoning the previous changesets with strip, and then moving MARK to MARK@N. Test coverage is added.

tags: update tag type only if tag node is updated (issue3911) Before this patch, tag type information is always updated, even if tag previously read in has higher priority than one newly read in. This causes that the tag type is displayed as "local", even if global tag overwrites existing local one successfully. This patch updates tag type only if tag node is updated. This patch tests overwriting local tags below: - visible one (normal case) - already removed one (recorded as null)

match: fix root calculation for combining regexps with simple paths The fall-back root for walking is the repo root, not no root. The "roots" do however also end up in m.files() which is used in various ways, for instance to indicate whether matches are exact. The change could thus have other impacts.

icasefs: enhance test to prevent regression by changes in the future This patch adds steps to test case-folding collision detection on the revision tree built up in the order different from the one reproducing issue3452. This may prevent regression by changes around "copy detection" and/or "case-folding collision detection" logic in the future.

icasefs: rewrite case-folding collision detection (issue3452) Before this patch, case-folding collision detection uses "copies.pathcopies()" before "manifestmerge()", and is not aware of renaming in some cases. For example, in the case of issue3452, "copies.pathcopies()" can't detect renaming, if the file is renamed at the revision before common ancestor of merging. So, "hg merge" is aborted unexpectedly on case insensitive filesystem. This patch fully rewrites case-folding collision detection, and relocate it into "manifestmerge()". New implementation uses list of actions held in "actions" and "prompts" to build provisional merged manifest up. Provisional merged manifest should be correct, if actions required to build merge result up in working directory are listed up in "actions" and "prompts" correctly. This patch checks case-folding collision still before prompting for merge, to avoid aborting after some interactions with users. So, this assumes that user would choose not "deleted" but "changed". This patch also changes existing abort message, because sorting before collision detection changes order of checked files.

icasefs: refactor "test-casecollision-merge.t" to reuse in succeeding fixes This patch refactors "test-casecollision-merge.t" to increase reusability in succeeding patches. It is confirmed that changed test also can detect issue3370.

icasefs: ignore removed files at building "dirstate._foldmap" up on icasefs Before this patch, all files in dirstate are used to build "_foldmap" up on case insensitive filesystem regardless of their statuses. For example, when dirstate contains both removed file 'a' and added file 'A', "_foldmap" may be updated finally by removed file 'a'. This causes unexpected status information for added file 'A' at "hg status" invocation. This patch ignores removed files at building "_foldmap" up on case insensitive filessytem. This patch doesn't add any test, because this issue is difficult to reproduce intentionally: it depends on iteration order of "dirstate._map".

i18n-pt_BR: synchronized with 3f5e75c22585

merge with i18n

i18n-ja: synchronized with f01a351db791

dispatch: add support for --option=value to _earlygetopt This fixes a very confusing error message: $ hg --config=pager.enabled=off st abort: option --config may not be abbreviated!

dispatch: add doctests for _earlygetopt

push: make locking of source optional (issue3684) Having the permission to lock the source repo on push is now optional. When the repo cannot be locked, phase are not changed locally. A status message is issue when some actual phase movement are skipped: cannot lock source repo, skipping local public phase update A debug message with the exact reason of the locking failure is issued in all case.

push: factorise phase movement in a simple closure Having all phases movement centralised will help to handle special case when the local repo can not be locked as describe in issue 3684.

merge: increase safety of parallel updating/removing on icasefs "merge.applyupdates()" sorts "actions" in removal first order, and "workeractions" derived from it should be also sorted. If each actions in "workeractions" are executed in serial, this sorting ensures that merging/updating process is collision free, because updating the file in target context is always executed after removing the existing file which causes case-folding collision against the former. In the other hand, if each actions are executed in parallel, updating on a worker process may be executed before removing on another worker process, because "worker.partition()" partitions list of actions regardless of type of each actions. This patch divides "workeractions" into removing and updating, and executes the former first. This patch still scans "actions"/"workeractions" some times for ease of patch review, even though large list may cost much in this way. (total cost should be as same as before) This also changes some tests, because dividing "workeractions" affects progress indication.

hgweb: handle filtered "0" rev in navigation Before this changeset, navigation generation crashed if revision "0" was filtered. We introduce a `_first` methods on revision navigation that return the lowest unfiltered element and use it in two place were the "0" changeset was explicitly referenced. Test case are introduced.

hgweb: fix empty navigation detection For some obscure reason, changelog.node(0) returns nullid if changelog is empty. this break empty navigation detection. We fix this code by using the length of the changelog. Using the length have some issue with revision filtering but this is a small step in the right direction. Proper fix comes in later changeset.

tests: AIX can't handle negative date in test-dirstate.t test-dirstate.t fails on AIX in the absurd date test. AIX touch errors on any date prior to 1970. AIX mktime() gives an error on such dates, so the problem is deeper than touch and attempts to work around touch in Python failed. Give up. Add an AIX test to hghave and skip the absurd date test on AIX.

win32: use explicit path to "python.exe" only if it exists Before this patch, "hg.bat" for Windows environment always uses "%~dp0..\python" as explicit path to "python.exe". This path may not be valid in some cases. For example, on the environment using "virtualenv" python package, both "python.exe" and "hg.bat" are placed in the same directory. In this case, "python.exe" should be found on PATH, because virtualenv activation script puts "python.exe" on the PATH. This patch uses explicit path to "python.exe" only if it exists, and expects that "python.exe" can be found on PATH otherwise.

test-mq-strip.t: add a test for strip --keep with clean working dir This helped uncover a bug in a patchset I've been writing.

largefiles: use repo.wwrite for writing standins (issue3909)

largefiles: drop repo wrapping detection After 257afe5489d4 I see: $ hg id -q largefiles: repo method 'commit' appears to have already been wrapped by another extension: largefiles may behave incorrectly largefiles: repo method 'push' appears to have already been wrapped by another extension: largefiles may behave incorrectly be207d9b7e4b The warning is bad: * The message gives no hint what the problem is and how it can be resolved. The message is useless. * Largefiles do have its share of problems, but I don't think I ever have seen a problem where this warning would have helped. The 'may' in the warning seems like an exaggeration of the risk. Having largefiles enabled in combination with for instance mq, hggit and hgsubversion causes a warning (depending on the configuration order) but do not cause problems. Extensions might of course be incompatible, but they can be that in many other ways. The check and the message are incorrect. It would thus be better to remove the check and the warning completely. Before 257afe5489d4 the check always failed. That change made the check work more like intended ... but the intention was wrong. This change will thus also back that change out.

config: discard "%unset" values defined in the other files read in previously Before this patch, "%unset" can't unset values defined in the other files read in previously, even though online help document says that it can. It can unset only values defined in the same configuration file. For example, the value defined in "~/.hgrc" can't be unset by "%unset" in ".hg/hgrc" of the repository. This patch records "%unset"-ed values in "config.parse()", and discards corresponding values in "config.update()".

tests: rename from test-config-case.t to test-config.t for centralization Before this patch, there is no test script testing configuration handling generally. "test-config-case.t" seems to be specific for testing case sensitive configuration. This patch renames from "test-config-case.t" to "test-config.t" for centralization of tests around configuration handling.

i18n: show the non-ASCII password prompt text correctly Before this patch, the prompt text for asking password is directly passed to "getpass.getpass()" of Python standard library. In "getpass.getpass()" implementation on Windows environment, the prompt text is split into byte sequence and "msvcrt.putch()" is applied on each bytes in it. This splitting causes non-ASCII prompt text to be broken. This patch shows the prompt text for asking password on "ui.getpass()" side, and invokes "getpass.getpass()" with empty prompt text. This prevents non-ASCII prompt text from being broken in "getpass.getpass()" implementation. This patch also sets "ui.prompt" label to prompt text to follow "ui.prompt()" style.

tests: make sed usage in test-unionrepo.t cross-platform Usage of the 'i' command proves tricky. I tried to write a check-code rule, but failed.

check-code: fix sed 'i' command rule newline matching The regular expression was meant to match cases where an 'i' command was not followed by precisely a '\' and then a newline; it failed to match the newline, so cases with a '\' but no newline would erroneously pass.

blackbox: don't run permission tests on non-unix systems The windows and vfat test runs were failing due to read/write permissions not working the same on those systems. On vfat, permissions can't be changed at all, and on windows it seems the chmod emulation doesn't remove read permissions. We could theoretically get the 'cannot write to blacklog.log' test to pass on windows but there's no #if condition to let us exclude vfat only. Verified that test-blackbox passes on windows now.

check-code: expand sed rule to include more offenders Expands the rule added in 5e4491c114b2 to include cases where the address is a line number instead of a regular expression, and fixes an instance of this pattern in test-unionrepo.t.

check-code: add a rule against a GNU sed-ism BSD sed requires the 'i' command to be followed with a backslash and a newline, like so: $ sed -e '/^@/i\ > other' We've encountered this problem before, e.g. in test-mq.t (900767dfa80d). This change adds a check-code rule and fixes two instances of the problem in test-record.t.

hgweb: make help verbose again (issue3899) Due to regression introduced in f5db3092790f, help in hgweb was rendered in non-verbose form (issue3899)

merge with i18n

i18n-pt_BR: synchronized with 64ea454e7d76

css: remove repeated property 'margin' property was repeated for the same selector

css: fixed font-family There is no 'sans' font-family, replaced with 'sans-serif'

color: add a test with extension loaded and ui.formatted=False

color: set _colormode to None when mode is unset (issue3895) Previously, colorui assumed that it would only be called when mode wasn't None. 7ae12ce87594 changed that, so now colorui needs to care about whether it should colorize output.

color: turn colorui functions into forwards when color is None colorui will be set to None as necessary in an upcoming patch.

largefiles: fix typos in documentation

translations: change label integer error to not specify the kind of label The current error message used the kind (bookmark, branch, tag) in the message. Unfortunately this isn't easily translatable since some languages give different genders to these words. The fix is to not specify it at all, since it should be implicit based on the command the user just ran. Relevant discussions around this area: http://selenic.com/pipermail/mercurial-devel/2012-October/045567.html http://selenic.com/pipermail/mercurial-devel/2012-October/045600.html

Added signature for changeset 292cd385856d

Added tag 2.6-rc for changeset 292cd385856d

merge default int stable for 2.6 code freeze

blackbox: automatically rotate log files If enabled, log rotation prevents the amount of space used by the blackbox log from growing without bound. This becomes important in cases where there are a lot of busy repositories managed by humans and automation on many machines. In large deployments, we cannot reasonably track all the repos where blackbox logs need to be managed, so it is safer to have blackbox manage its own logs than to move responsibility to an external tool such as logrotate. This change adds two configuration keys: * blackbox.maxsize is the maximum allowable size of the current log * blackbox.maxfiles is the number of log files to maintain

ui: add a configbytes method, for space configuration This accepts a floating point number, followed by optional whitespace, followed by an optional one- or two-letter unit specifier (for bytes, kilobytes, megabytes, or gigabytes).

mq: do not inherit settings form base repo in mqrepo (Fixes issue2358) This is done by using repo.baseui when creating the queue repo.

color: set the ui class in reposetup, before a repo is created Previously only the class of repo.ui was set. The class was set in the wrapper of dispatch._runcommand. But this is called after the repo is created. Only the class of repo.ui is set because repo.baseui already exists and is not accessible. We now set the class in uisetup because this is called before repo creation. This is also the place suggested in the wiki for modifying classes.

parsers: remove warning: format ‘%ld’ expects argument of type ‘long int’ gcc 4.6.3 on 12.04 Ubuntu machine emits warnings: mercurial/parsers.c: In function ‘find_deepest’: mercurial/parsers.c:1288:9: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘Py_ssize_t’ [-Wformat] mercurial/parsers.c:1288:9: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘Py_ssize_t’ [-Wformat]

annotate: discard refcount of discarded annotation for memory efficiency Before this patch, refcount (managed in "needed") of the annotation result is kept as 1, even if corresponding annotation result is discarded from "hist", because it isn't decreased and discarded. In the history tree including merging revision, the most recent common ancestor of merged revisions is scanned twice. Refcount of such ancestor never becomes 0, because refcount is started from 1 at the second scanning. This prevents annotation results of merging revision in "hist" from being discarded, and decreases memory efficiency. This patch discards refcount of the annotation result, when the corresponding annotation is discarded from "hist".

revlog: fix a regression with null revision Introduced in the patch which fixes issue3497 Part of that patch was erroneously submitted and it shouldn't be in the code

rebase: check no-op before checking phase (issue3891) This could lead to user confusion, because phases aren't really involved at all when attempting to perform a no-op rebase.

template: call runtemplate on the src argument to sub This allows using a template keyword on calls to the sub function and brings the function inline with most other semantics of the other template functions.

run-tests: introduce --random for running tests in random error This is convenient when investigating failures one by one to avoid running the same fixed tests first every time.

largefiles: wlock in status before lfdirstate.write()

transplant: use set for prune lookup

obsolete: extract obsolescence marker pulling into a dedicated function Having a dedicated function will allow us to experiment with other exchange strategies in an extension. As we have no solid clues about how to do it right, being able to experiment is vital. Some transaction tricks are necessary for pull. But nothing too scary.

obsolete: extract obsolescence marker pushing into a dedicated function Having a dedicated function will allows us to experiment with other exchange strategies in an extension. As we have no solid clues about how to do it right, being able to experiment is vital. I intended a more ambitious extraction of push logic, but we are far too advanced in the release cycle for it.

blackbox: fix a case of name capture

pathencode: eliminate comma at end of enum list to avoid pedantic warning

smtp: use 465 as default port for SMTPS Before this patch, port 25 (wellknown port of SMTP) is used as default port, even if "[smtp] tls" is configured as "smtps". This patch uses port 465 (wellknown port of SMTPS) as default port, if "[smtp] tls" is configured as "smtps".

subrepo: fix test breakage introduced in 2b34d004e644 The test didn't break when I originally committed it (git version 1.7.12.4 (Apple Git-37)), and still doesn't on that machine, but the output changes elsewhere with "Warning: you are leaving N commits behind..." This change sets a ref on the commit we're updating the subrepo _away_ from to quash the warning.

histedit: more precise user message when changeset is missing Now that we explicitly detect duplicated changesets, we can explicitly detect missing ones. We cover the same cases as before, some others and we offer a better error message in all cases.

histedit: protect against duplicated entries Before this change one would issue rules with duplicated entries. For this to happen some other changeset had to be missing to maintain the rules length.

histedit: track short hash instead of changectx object This simplifies set usage and allow us to add a missing revision check in a later commit.

histedit: ensure rules return short hex at all time Handling homogeneous data is both simpler and safer.

histedit-test: test unknown command We had no tested for this case.

histedit-test: test unknown changeset We had no tested for this case.

histedit-test: test malformed line We had not tested for this case.

histedit-test: test that extra revisions are detected We had not tested for this case.

histedit-test: test that missing revisions are detected We had not tested for this case.

histedit: handle multiple spaces between action and hash (issue3893) There is some clue that the previous code intended to handle that but it was actually not the case. As a result action could apply to the empty string '' changeset, leading to the use the current working directory parent in some operations.

http2: sane readline It turns out that it pays off to read more than a byte at a time with a select in between :)

http2: make read use pushchunk/popchunk, eschew itertools The itertools approach was showing up high in the profile output.

http2: track available data as it changes instead of recomputing it With a large amount of available data, this computation can become costly.

histedit-test: rename histedit-revspec into histedit-argument We have no testing for argument. This small file seems perfect once but needs a rename.

histedit-test: remove unnecessary graphlog extension Graphlog is now in core.

histedit-test: drop skip logic for older mercurial version We are shipped in core now.

hgweb: refactor checks for granting and revoking user permissions Provides an entry point for extensions implementing more complex authorization schemes. Original patch proposed by Markus Zapke-Gründemann.

check-code: add check for lock release order

parsers: fix variable declaration position issue

zsh_completion: complete all files for `commit/backout --logfile` Up until now commit/backout `--logfile` option was completed only with *.txt-files. This requirement is a bit too strong (and is nowhere to be stated) so it's better to complete with all files. Stolen from zsh.git repo, c5fce37b changeset by Oliver Kiddle.

transplant: improve documentation

transplant: clarify what --branch do - it has nothing to do with branches --branch specifies heads and has nothing to do with named branches, and it only deals with topological branches to the same extent as all other DAG operations do.

import: inline checkexact function We have a sngle call now, no need to make it a function.

import: factor out checkexact The two calls are strictly identical. We can simply move it after the if/else clause.

amend: fix unlocking order - first lock then wlock

codingstyle: remove trailing spaces in various text files Better do it once than see random changes in diffs later.

tests: run check-code on Python files without .py extension

histedit: move outgoing processing to its own function Every piece of code extracted from the main command is a win. We simplify changeset determination in the process. Parent ceases being a list before becoming a node. We how have a root variable containing a node all the time.

histedit: move all arguments checks to the beginning of the command This changeset move all checks and raises related to arguments validation to the top of the file. This gathers all the logic in one place and clarifies the code doing actual work. This paves the way for splitting this gigantic function in separated functions. A `goal` variable is introduced in the process. It holds the action to be done by this invocation (new, continue or abort). An invalid invocation is found in the process (the new code is a bit stricter).

histedit-test: generalise --commands "-" usage This is simpler than temporary file version. There some minor test changes since commit messages are no longer modifed. There is still some tests using --commands with a real file.

histedit: allow "-" as a command file When "-" is specified as a command file, we read rules from stdin. Alter a single test to demo the behavior, but most of them could benefit from this. There is minor change in test output resulting from the fact we no longer change log messages.

histedit: properly handle --continue on empty fold When all changes from the fold have been dropped, the --continue code was confused. This changeset handles this case. The test for this case existed but was broken.

histedit-test: replace obscure python script by a plain file One of the tests uses a python script to edit the histedit commands on the fly. It was hard to read and likely to break. This is replaced by a plain command file. Doing so made me discover that the python script is incorrect. The "+6" regexp never matched because the revision number is wrong. This error is kept in the replacement for now. Fixing the histedit command triggers a traceback in histedit. A later changeset will fix the error and restore the intended test.

test: improve documentation of some histedit tests Each test section is clearly separated from the others and gains some helpful documentation.

test: use a lighter log style in histedit test The default log displays a log of information that is useless for histedit tests. Having a cleaner log help readability of those tests a lot. This does not change anything to the test semantic.

subrepo: add regression test for issue3870

subrepo: clone of git sub-repository creates incorrect git branch (issue3870) Mercurial handles git subrepos by incorrect way. If the mercurial repo has a git sub-repo and somebody started a new branch in the subrepo and push it into git, the next one who will clone the whole repo will get incorrect branch name in the git subrepo.

dispatch: print 'abort:' when a pre-command hook fails (BC) This also changes the exit code from whatever the hook returned to 255. This brings it in line with all the other hooks that abort.

largefiles: don't hash all largefiles when initializing a lfdirstate The largefiles will be hashed on demand if necessary ... and sometimes it isn't necessary.

largefiles: use filechunkiter for iterating largefile when serving getlfile The default file iterator is line based and will give odd chunk sizes - often very short and relatively expensive.

largefiles: stat all largefiles in one batch before downloading This avoids a lot of expensive roundtrips to remote repositories ... but might be slightly slower for local operations. This will also change some aborts on missing files to warnings. That will in some situations make it possible to continue working on a repository with missing largefiles.

largefiles: 'put' should store 'source' file in under 'hash', also in localstore

largefiles: getlfile must hit end of HTTP chunked streams to reuse connections We did read the exactly the right number of bytes from the response body. But if the response came in chunked encoding then that meant that the HTTP layer still hadn't read the last 0-sized chunk and expected the app layer to read more data from the stream. The app layer was however happy and sent another request which had to be sent on another HTTP connection while the old one was lingering until some other event closed the connection. Adding an extra read where we expect to hit the end of file makes the HTTP connection ready for reuse. This thus plugs a real socket leak. To distinguish HTTP from SSH we look at self's class, just like it is done in putlfile.

largefiles: drop limitreader, use filechunkiter limit filechunkiter.close was a noop.

largefiles: move protocol conversion into getlfile and make it an iterable Avoid the intermediate limitreader and filechunkiter between getlfile and copyandhash - return the right protocol and put the complexity where it better can be managed.

largefiles: don't close the fd passed to store._getfile

largefiles: remove blecch from lfutil.copyandhash - don't close the passed fd

largefiles: drop lfutil.blockstream - use filechunkiter like everybody else The old chunk size is kept - just to avoid changing it.

largefiles: refactoring - use findfile in localstore._getfile

largefiles: refactoring - return hex from _getfile and copyandhash

largefiles: refactoring - create destination dir in lfutil.link

summary: clear "commonincoming" also if branches are different Before this patch, "commonincoming" calculated by "discovery.findcommonincoming()" is cleared, only if "default" URL without branch part (tail "#branch" of URL) differs from "default-push" URL without branch part. But common revisions in "commonincoming" calculated for a branch doesn't include ones for another branch, even if URLs without branch part are same. The result of "discovery.findcommonoutgoing()" invocation with such "commonincoming" becomes incorrect in some cases. This patch clears "commonincoming", also if branch part of "default" differs from one of "default-push". To avoid redundant looking up: - "ui.expandpath('default')" and "ui.expandpath('default-push', 'default')" are not compared directly, even though they contain branch information, because they are not yet normalized by "hg.parseurl()": tail "/" of path, for example - "commonincoming" is not cleared, if branch isn't specified in "default" URL, because such "commonincoming" contains common revisions for all branches This patch also tests "different path, same branch" pattern to check careless degrading around comparison between source and destination.

summary: make "incoming" information sensitive to branch in URL (issue3830) Before this patch, "incoming" information of "hg summary --remote" is not sensitive to the branch specified in the URL of the destination repository, even though "hg pull"/"hg incoming" are so. Invocation of "discovery.findcommonincoming()" without "heads" argument treats revisions on branches other than the one specified in the URL as incoming ones unexpectedly. This patch looks head revisions, which are already detected by "hg.addbranchrevs()" from URL, up against "other" repository, and invokes "discovery.findcommonincoming()" with list of them as "heads" to limit calculation of incoming revisions.

histedit: make "hg histedit" sensitive to branch in URL Before this patch, "hg histedit" are not sensitive to the branch specified in the URL of the destination repository, even though "hg push"/"hg outgoing" are so: Invocation of "discovery.findcommonoutgoing()" without "onlyheads" argument treats revisions on branches other than the one specified in the URL as outgoing ones unexpectedly. This patch specifies list of head revisions, which are already detected by "hg.addbranchrevs()" from URL and looked up against local repository, as "onlyheads" to "discovery.findcommonoutgoing()" to limit calculation of outgoing revisions.

summary: make "outgoing" information sensitive to branch in URL (issue3829) Before this patch, "outgoing" information of "hg summary --remote" is not sensitive to the branch specified in the URL of the destination repository, even though "hg push"/"hg outgoing" are so: Invocation of "discovery.findcommonoutgoing()" without "onlyheads" argument treats revisions on branches other than the one specified in the URL as outgoing ones unexpectedly. This patch looks head revisions, which are already detected by "hg.addbranchrevs()" from URL, up against local repository, and invokes "discovery.findcommonoutgoing()" with list of them as "onlyheads" to limit calculation of outgoing revisions.

annotate: increase refcount of each revisions correctly (issue3841) Before this patch, refcount (managed in "needed") of parents of each revisions in "visit" is increased, only when parent is not annotated yet (examined by "p not in hist"). But this causes less refcount of the revision like "A" in the tree below ("A" is assumed as the second parent of "C"): A --- B --- C \ / \-----/ Steps of annotation for "C" in this case are shown below: 1. for "C" 1.1 increase refcount of "B" 1.2 increase refcount of "A" (=> 1) 1.3 defer annotation for "C" 2. for "A" 2.1 annotate for "A" (=> put result into "hist[A]") 2.2 clear "pcache[A]" ("pcache[A] = []") 3. for "B" 3.1 not increase refcount of "A", because "A not in hist" is False 3.2 annotate for "B" 3.3 decrease refcount of "A" (=> 0) 3.4 delete "hist[A]", even though "A" is still needed by "C" 3.5 clear "pcache[B]" 4. for "C", again 4.1 not increase refcount of "B", because "B not in hist" is False 4.2 increase refcount of "A" (=> 1) 4.3 defer annotation for "C" 5. for "A", again 5.1 annotate for "A" (=> put result into "hist[A]", again) 5.2 clear "pcache[A]" 6. for "C", once again 6.1 not increase refcount of "B", because "B not in hist" is False 6.2 not increase refcount of "A", because "A not in hist" is False 6.3 annotate for "C" 6.4 decrease refcount of "A", and delete "hist[A]" 6.5 decrease refcount of "B", and delete "hist[B]" 6.6 clear "pcache[C]" At step (5.1), annotation for "A" mis-recognizes that all lines are created at "A", because "pcache[A]" already cleared at step (2.2) prevents from scanning ancestors of "A". So, annotation for "C" or its descendants loses information about "A" or its ancestors. The root cause of this problem is that refcount of "A" is decreased at step (3.3), even though it isn't increased at step (3.1). To increase refcount correctly, this patch increases refcount of each parents of each revisions: - regardless of "p not in hist" or not, and - only once for each revisions in "visit" (by "not pcached") In fact, this problem should occur only on legacy repositories in which a filelog includes the merging between the revision and its ancestor (as the second parent), because: - tree is scanned in depth-first without such merging, revisions in "visit" refer different revisions as parent each other - recent Mercurial doesn't allow such merging changelog and manifest can include such merging someway, but filelogs can't, because "localrepository._filecommit()" converts such merging request to linear history. This patch tests merging cases below: these cases are from filelog of "mercurial/commands.py" in the repository of Mercurial itself. - both parents are same 10 --- 11 --- 12 \_/ filelogrev: changesetid: 10 00ea3613f82c 11 fc4a6e5b5812 12 4f802588cdfb - the second parent is also ancestor of the first one 37 --- 38 --- 39 --- 40 \________/ filelogrev: changesetid: 37 f8d56da6ac8f 38 38919e1c254d 39 d3400605d246 40 f06a4a3b86a7

annotate: reuse already calculated annotation Before this patch, annotation is re-calculated even if it is already calculated. This may cause unexpected annotation, because already cleared "pcache" ("pcache[f] = []") prevents from scanning ancestors. This patch reuses already calculated annotation if it is available. In fact, "reusable" situation should be seen only on legacy repositories in which a filelog include the merging between the revision and its ancestor, because: - tree is scanned in depth-first without such merging, annotation result should be released soon - recent Mercurial doesn't allow such merging changelog and manifest can include such merging someway, but filelogs can't, because "localrepository._filecommit()" converts such merging request to linear history.

log: fix behavior with empty repositories (issue3497) Make output in this special case consistent with general case one.

merge with crew

revlog: don't cross-check ancestor result against Python version

parsers: a C implementation of the new ancestors algorithm The performance of both the old and new Python ancestor algorithms depends on the number of revs they need to traverse. Although the new algorithm performs far better than the old when revs are numerically and topologically close, both algorithms become slow under other circumstances, taking up to 1.8 seconds to give answers in a Linux kernel repo. This C implementation of the new algorithm is a fairly straightforward transliteration. The only corner case of interest is that it raises an OverflowError if the number of GCA candidates found during the first pass is greater than 24, to avoid the dual perils of fixnum overflow and trying to allocate too much memory. (If this exception is raised, the Python implementation is used instead.) Performance numbers are good: in a Linux kernel repo, time for "hg debugancestors" on two distant revs (24bf01de7537 and c2a8808f5943) is as follows: Old Python: 0.36 sec New Python: 0.42 sec New C: 0.02 sec For a case where the new algorithm should perform well: Old Python: 1.84 sec New Python: 0.07 sec New C: measures as zero when using --time (This commit includes a paranoid cross-check to ensure that the Python and C implementations give identical answers. The above performance numbers were measured with that check disabled.)

revlog: choose a consistent ancestor when there's a tie Previously, we chose a rev based on numeric ordering, which could cause "the same merge" in topologically identical but numerically different repos to choose different merge bases. We now choose the lexically least node; this is stable across different revlog orderings.

ancestor: a new algorithm that is faster for nodes near tip Instead of walking all the way to the root of the DAG, we generate a set of candidate GCA revs, then figure out which ones will win the race to the root (usually without needing to traverse all the way to the root). In the common case of nodes that are close to each other in both revision number and topology, this is usually a big win: it makes "hg --time debugancestors" up to 9 times faster than the more general ancestor function when measured on heads of the linux-2.6 hg repo. Victory is not assured, however. The older function can still win by a large margin if one node is much closer to the root than the other, or by a much smaller amount if one is an ancestor of the other. For now, we've also got a small paranoid harness function that calls both ancestor functions on every input and ensures that they give equivalent answers. Even without the checker function, the old ancestor function needs to stay alive for the time being, as its generality is used by context.filectx.merge.

update: allow dirty update to foreground (successors) Update to "foreground" are no longer seen as cross branch update. "Foreground" are descendants or successors (or successors of descendants (or descendant of successors (etc))). This allows to update with uncommited changes that get automatically merged. This changeset is a small step forward. We want to allow dirty update to "background" (precursors) and takes obsolescence in account when finding the default update destination. But those requires deeper changes and will comes in later changesets.

obsolete: extract foreground computation from bookmark.validdest This foreground logic will be reused by update logic.

destroyed: invalidate phraserevs cache in all case (issue3858) When revisions are destroyed, the `phaserevs` cache becomes invalid in most case. This cache hold a `{rev => phase}` mapping and revision number most likely changed. Since 1c8e0d6ac3b0, we filter unknown phases' roots after changesets destruction. When some roots are filtered the `phaserevs` cache is invalidated. But not if none root where destroyed. We now invalidate the cache in all case filtered root or not. This bug was a bit tricky to reproduce as in most case we either: * rebase a set a draft changeset including root (phaserev invalidated) * strip tip-most changesets (no re-numbering of revision) Note that the invalidation of `phaserevs` are not strictly needed when only tip-most part of the history have been destroyed. But I do not expect the overhead to be significant.

largefiles: deprecate --all-largefiles for pull The same can be achieved with --lfrev pulled() and we shouldn't advertise unnecessary command line options.

largefiles: implement pull --all-largefiles as a special case of --lfrev

largefiles: drop --cache-largefiles again This goes a step further than d69585a5c5c0 and backs out the unreleased --cache-largefiles option. The same can be achieved with --lfrev heads(pulled()) and we shouldn't introduce unnecessary command line options.

largefiles: introduce pulled() revset expression for use in --lfrev This provides a general way to do what already can be done with --all-largefiles and --cache-largefiles.

largefiles: introduce pull --lfrev option The revset will be evaluated after the changesets has been pulled, and missing largefiles from matching revisions will be pulled to the local caches. This in combination with revsets will make it possible to specify different strategies for pulling largefiles. The revset expressions used for this option might be quite complex and will probably be most useful from scripts or an alias ... but less complicated than configuring hooks.

largefiles: refactor overridepull internals

largefiles: introduce lfpull command for pulling missing largefiles

largefiles: update help Some clarifications, and some clean-up after --cache-largefiles was introduced.

largefiles: fix cat of non-largefiles from subdirectory We were calling back to the original commands.cat from inside the walk loop that handled and filtered out largefiles. That did however happen with file paths relative to repo root and the original cat would fail when it applied its own walk and match on top of that. Instead we now duplicate and modify the code from commands.cat and patch it to handle both normal and largefiles. A change in test output shows that this also makes the exit code with largefiles consistent with the normal one in the case where one of several specified files are missing. This also fixes the combination of --output and largefiles.

largefiles: don't store whole file in memory for 'cat'

mergetools: rename 'base' to 'merged' in meld This makes it clear which panel is the target of the merge operation.

mergetools: avoid losing the merged version with meld Add -o $output. When using Meld as intended (merge from left and right into the center panel), the merged version is written to the wrong file without this option ($base, a temporary file, which is ignored by Mercurial). Add meld.check=changed as a secondary safety net.

templatekw: add default styles for hybrid types (issue3887) This allows elements like file_copies to be printed as 'name (source)' when used with join.

largefiles: improve repo wrapping detection Before this patch, repo wrapping detection in "reposetup()" of largefiles can detect only limited repo wrapping: replacing target functions by another one named as "wrap". So, it can't detect repo wrapping even in recommended style: replacing "__class__" of repo by derived class. This patch can detect repo wrapping in both styles below: - replacing "__class__" of repo by derived class (recommended style): class derived(repo.__class__): def push(self, *args, **kwargs): return super(derived, self).push(*args, **kwargs) repo.__class__ = derived - replacing function of repo by another one (not recommended style): orgpush = repo.push def push(*args, **kwargs): return orgpush(*args, **kwargs) repo.push = push

hgweb: respond HTTP_NOT_FOUND when an archive request does not match any files

archive: raise error.Abort if the file pattern matches no files Note that we could raise this exception even if no pattern were specified, but the revision contained no files. However this should not happen in practice since in that case commands.py/archive would exit earlier with an "no working directory: please specify a revision" error message instead.

ui: add 'force' parameter to traceback() to override the current print setting This will allow a current traceback.print_exc() call in dispatch to be replaced with ui.traceback() even if --traceback was not given on the command line.

ui: add support for fully printing chained exception stacks in ui.traceback() Currently, only SubrepoAbort has a cause chained to it.

subrepo: chain the original exception to SubrepoAbort The tracebacks in subrepos are truncated at the point where the original exception is caught and SubrepoAbort is raised in its place since 9e3910db4e78. That hides the most relevant subrepo methods when an error occurs. Python 2.x doesn't support chaining exceptions, so it is manually done here for manual printing later.

debugrebuildstate: rename to debugrebuilddirstate There is a lot of state, but this command is for rebuilding the dirstate.

debugstate: rename to debugdirstate There is a lot of state, but this command is for debugging the dirstate.

debugrebuildstate: clarify that rev can't be specified without -r -r has a default value of '' in the command line. The function default value of 'tip' is thus never used and any attempt at specifying revisions without -r will fail. It seems like then intended behavior was that 'hg debugrebuildstate' without any parameters should set the parents to tip. That would be very confusing now when the command primarily is used to recover from incorrect stat info. It is apparently undocumented that '' is the same as '.' ... unless it is passed in a place where revsets are used.

check-code: check txt files for trailing whitespace

check-code: catch trailing space in comments

spelling: fix typos and spelling errors

wireproto: clarify cryptic 'remote: unsynced changes' error message on push The message was not very much to the point and did not in any way help an ordinary user. 'repository changed while preparing/uploading bundle - please try again' is more correct, gives the user some understanding of what is going on, and tells how to 'recover' from the situation. The 'bundle' aspect could be seen as an implementation detail that shouldn't be mentioned, but I think it helps giving an exact error message. The message could still leave the user wondering why Mercurial doesn't lock the repo and how unsafe it thus is. Explaining that is however too much detail.

export: export working directory parent by default A common usecase for export is to preview the patch that will be patchbombed or to see what changed in a revision found by bisect. Showing the working directory parent is thus a useful and obvious default.

commit: allow closing "non-head" changesets Backout acd61dc44a39. The changeset prevented closing non-head changesets but did not provide any rationale or test case and I don't see what value it adds. Users might have their reasons to commit something anywhere - and close it immediately. And contrary to the comment that is removed: The topo heads set is _not_ included in the branch heads set of the current branch. It do not include closed topological heads. The change thus prevented closing commits on top of closing commits. A valid usecase for that is to merge closed heads to reduce the number of topological heads. The only existing test coverage for this is the failing double close in test-revset.t. It was added in 3cc2e34d7a7d and seems to not be intentional.

record: ignore trailing content when parsing patches - introduce 'other' lines This makes record work more like import which ignores for instance mail footers in a patch file. This also makes it possible for TortoiseHg to preview unapplied patches containing such footers.

record: abort on malformed patches instead of crashing

localrepo: use "vfs.rename()" instead of "util.rename()" This patch makes "_journalfiles()" return a list of pairs of journal file and corresponded vfs instance instead of a list of journal files in full path, to use "vfs.rename()" instead of "util.rename()" in "aftertrans()". "undofiles()" still returns a list of undo files in full path, because "repair.strip()" expects such list. It'll be also made to return a list of pairs of undo file and corresponded vfs at vfs migration for "repair.strip()" in the near future.

localrepo: use "vfs.setflags()" instead of "util.setflags()"

localrepo: use "vfs.readlink()" instead of "os.readlink()"

localrepo: use "vfs.islink()" instead of "os.path.islink()"

localrepo: use "vfs.rename()" instead of "util.rename()"

localrepo: use "vfs.exists()" instead of "os.path.exists()"

localrepo: use vfs instead of "os.path.*" in sharedpath checking In the point of view of efficiency, "vfs" instance created in this patch should be passed to and reuse in "store.store()" invocation just after patched code block, because "store" object is initialized by vfs created with "self.sharedpath". eBut to focus just on migration from direct file I/O API accessing to vfs, this patch uses created vfs as temporary one. Refactoring around "store.store()" invocation will be done in the future.

vfs: split "expand" into "realpath"/"expandpath" to apply each separately Before this patch, vfs constructor applies both "util.expandpath()" and "os.path.realpath()" on "base" path, if "expand" is True. This patch splits it into "realpath" and "expandpath", to apply each functions separately: this splitting can allow to use vfs also where one of each is not needed.

unionrepo: read-only operations on a union of two localrepos unionrepo is just like bundlerepo without bundles. The implementation is very similar to bundlerepo, but I don't see any obvious way to generalize it. Some most obvious use cases for this would be log and diff across local repos, as a kind of preview of pulls, for instance: $ hg -R union:repo1+repo2 heads $ hg -R union:repo1+repo2 log -r REPO1REV -r REPO2REV $ hg -R union:repo1+repo2 log -r '::REPO1REV-::REPO2REV' $ hg -R union:repo1+repo2 log -r 'ancestor(REPO1REV,REPO2REV)' $ hg -R union:repo1+repo2 diff -r REPO1REV -r REPO2REV This is going to be used in RhodeCode, and Bitbucket already uses something similar. Having a core implementation would be beneficial.

subrepo: fix exception on revert when "all" option is omitted Since fafdff7e9c43, backout does not set opts['all'], which causes KeyError at hgsubrepo.revert.

histedit: update tests for new intervention framework

test-subrepo: add tests for subrepo "storeclean" checks These tests verify that subrepos are not pushed when their store is clean versus a given target repository.

subrepo: do not push mercurial subrepos whose store is clean This patch stops mercurial from pushing unmodified subrepos. An unmodified subrepo is one whose store is "clean" versus a given target subrepo. Note that subrepos may have a clean store versus a target repo but not versus another. This patch handles this scenario by individually keeping track of the state of the store versus all push targets. Tests will be added on the following revision.

subrepo: implement "storeclean" method for mercurial subrepos The mercurial subrepo "storeclean" method works by calculating a "store hash" of the repository state and comparing it to a cached store hash. The store hash is always cached when the repository is cloned from or pushed to a remote repository, but also on pull as long as the repository already had a clean store. If the hashes match the store is "clean" versus the selected repository. Note that this method is currenty unused, but it will be used by a later patch. The store hash is calculated by hashing several key repository files, such as the bookmarks file the phaseroots file and the changelog. Note that the hash comparison is done file by file so that we can exit early if a pair of hashes do not match. Also the hashes are calculated starting with the file that is most likely to be smaller upto the file that is more likely to be larger.

util: add notindexed optional parameter to makedirs function

subrepo: introduce storeclean method Currently this method is unused and it is not implemented for any specific subrepo type (it always returns False). It receives a remote repository path because a repository may have a clean store versus a given repository but not versus another.

subrepo: introduce storeclean helper functions These helper functions are currently unused but will be used to implement the cleanstore method that will be introduced later.

dispatch: exit with status 1 for an InterventionRequired exception (bc)

histedit: switch from util.Abort to util.InterventionRequired where appropriate (bc)

rebase: switch from util.Abort to util.InterventionRequired where appropriate (bc)

dispatch: catch InterventionRequired and print the message with no prefix

error: introduce new InterventionRequired exception Future changes will use this type instead of util.Abort for signalling the user that intervention is required, as in some rebase and histedit aborts.

util: remove unreachable code Found by Cython.

util: remove no-op assignment Found by Cython.

merge more evolve stuff away (what?)

synthrepo: add missing import of sys Found using Cython.

transplant: pass source through to recover

repoview: remove more unreachable code Found using Cython.

merge away some failed evolve fat-fingering

pager: add missing imports of errno and shlex Found using Cython.

largefiles: quiet (and document) undefined name errors (issue3886) These names were found using Cython; I was completely puzzled until I searched the rest of the tree. It's icky to mess with another module's namespace, but ickier yet to do so without a comment :-)

color: add missing import of error Found using Cython.

pvec: use the correct name for an identifier Found using Cython.

repoview: remove unreachable code Found using Cython.

pvec: use the correct name for an identifier Found using Cython.

repoview: remove unreachable code Found using Cython.

mail: add missing import of sys Found using Cython.

statichttprepo: add missing import of os Found using Cython.

worker: add missing import of errno Found using Cython.

histedit: support editing of the first commit (issue3767)

test-commit-amend.t: fix check-code violation from 3a72c89a83ec

util: improve doc for checkcase

scheme: don't crash on invalid URLs

amend: support amending merge changesets (issue3778)

worker: catch all exceptions, try to exit usefully/safely

lock: if we fork, ensure that only the parent releases This prevents us from having a bunch of errant worker processes all try to release a lock if a problem occurs. (Releasing the lock more than once is harmless; it's invoking the associated callbacks we want to avoid.)

tag: clarify cryptic error message when tagging null revision

setup: make error message for missing Python headers more helpful

obsolete: ensure all markers have a date Obsolescence creates a sparse DAG mostly composed of a lot of small independent chain of markers. Date is the only simple and "reliable" way to sort them. The existence of a date is now enforced at creation time as I'm more and more convinced that date will have a key role in obsolescence markers exchange.

zsh_completion: make use of `debuglabelcomplete` command Use `debuglabelcomplete` command when populating labels list, instead of calling `hg` three times: for branches, bookmarks and tags. Do not pass string being completed to `hg debuglabelcomplete` (as `$words[$CURRENT]`), since it breaks `_hg_revrange` completion (`--rev 2.5:2.5.<Tab>`) for no apparent benefit. Also complete `hg view` with labels, not just tags, and drop unused `_hg_tags`.

dirs: use mutable strings internally perfdirs results for a working dir with 170,000 files: Python 638 msec C 244 C+int 192 C+int+str 168 In the large repo above, the nearly 0.5 second time improvement is visible in commands like "hg add" and "hg update". hg add Python 1100 msec C+int+str 600 hg update (with nothing to do) Python 2800 msec C+int+str 2240

dirs: use mutable integers internally These integers are not visible to Python code, so this is safe. perfdirs results for a working dir with 170,000 files: Python 638 msec C 244 C+int 192

scmutil: rewrite dirs in C, use if available This is over twice as fast as the Python dirs code. Upcoming changes will nearly double its speed again. perfdirs results for a working dir with 170,000 files: Python 638 msec C 244

scmutil: use new dirs class in dirstate and context The multiset-of-directories code was open coded in each of these modules; this change gets rid of the duplication.

scmutil: add a dirs class This encapsulates the "multiset of directories" structures that are currently open-coded (and duplicated) in both the dirstate and context modules. This will be used, and optionally replaced by a C implementation, in upcoming changes.

scmutil: migrate finddirs from dirstate

merge

manifestmerge: handle workdir removed, remote removed with flags This can happen when a file with flags is removed or deleted in the working directory and also not present in m2. The obvious solution is to add a __delitem__ override to manifestdict that removes the file from flags if necessary, but that has a significant performance cost in some cases, e.g. hg status --rev rev1 --rev rev2 <file>.

dicthelpers.diff: compare against default for missing values This is not only a bit faster, but also aligns with callers' expectations better since we can legitimately have manifestdict's _flags set to '' instead of unset. hg perfmergecalculate -r . before: ! wall 0.139582 comb 0.140000 user 0.140000 sys 0.000000 (best of 59) after: ! wall 0.126154 comb 0.120000 user 0.120000 sys 0.000000 (best of 74) hg perfmergecalculate -r .^ before: ! wall 0.236333 comb 0.240000 user 0.240000 sys 0.000000 (best of 36) after: ! wall 0.212265 comb 0.210000 user 0.210000 sys 0.000000 (best of 45)