update: don't move the active bookmark if a rev is specified with -r

mq: fix qapplied --last and qprev documentation (issue3282) qapplied --last is qprev not qtop. v2: - Replace "previous" with "preceding" as suggested here and there

setup: handle output from Apple's Xcode 4.3 better (issue3277) Apparently, it prints nothing at all if the user installed only the command-line tools. In that case, don't try to parse the empty output -- just assume they have Xcode >= 4.

graphlog: apply file filters --patch/--stat output When passing --patch/--stat, file filters have to be applied to generate the correct diff or stat output: - Without --follow, the static match object can be reused - With --follow, the files displayed at revision X are the ancestors of selected files at parent revision. To do this, we reproduce the ancestry calculations done by --follow, lazily. test-glog.t changes show that --patch output is not satisfying because renames are reported as copies. This can probably be fixed by: - Without --follow: compute files to display, look for renames sources and extend the matcher to include them. - With --follow: detect .path() transitions between parent/child filectx, filter them using the linked changectx .removed() field and extend fcache with them.

context: add followfirst arg to filectx and workingfilectx When _followfirst() revset was introduced it seemed to be the sole user of such an argument, so filectx.ancestors() was duplicated and modified instead. It now appears this argument could be used when computing the set of files to be considered when --patch or --stat are passed along with --follow FILE.

graphlog: fix --removed "hg log --removed FILE" does not return changesets where FILE was removed, but ones where FILE was changed and possibly removed. The flag is really here to disable walkchangerevs() fast path, which cannot see file removals by scanning filelogs.

test-glog: rewrite more tests using testlog() function

match: consider filesets as "anypats" Matt suggested this on IRC, I do not think the choice is obvious, but this one makes things simpler because while filesets are turned into a list of files into the match objects, it would more be difficult to tell invalid files passed in pats from those expanded from filesets.

graphlog: evaluate FILE/-I/-X filesets on the working dir This subtlety is not documented yet but: - pats/--include/--exclude filesets are evaluated against the working directory - --rev filesets are reevaluated against every revisions

graphlog: implement --copies

test-check-code-hg: skip test if not in a working dir (issue3248).

copies: use ctx.dirs() for directory rename detection

copies: fix mergecopies doc mapping direction

merge with stable

log: restore cache used by --copies The {filelog -> linkrev -> copyfrom} cache was refactored and broken by: changeset: 10060:f780b1098efc user: Patrick Mezard <pmezard@gmail.com> date: Sun Dec 13 18:06:24 2009 +0100 summary: templatekw: change {file_copies} behaviour, add {file_copies_switch} With --copies, this cache is accessed for every touched file of every revision. Unfortunately it is recreated for every revision, which means filelogs are parsed again. This patch makes the cache global again for all revisions. A couple of indicative timings of "hg log --copies", before and after: hg: 44s / 5s mozilla --limit 10000: 3m51s / 2m32s mozilla: 23m46s / 12m23s I do not know any good tool to trace memory consumption of these runs for comparisons. Watching the full mozilla run in top, the process did not seem to misbehave.

graphlog: implement --follow-first log --graph --follow-first FILE cannot be compared with the regular version because it never worked: --follow-first is not taken in account in walkchangerevs() fast path and is explicitely bypassed in FILE case in walkchangerevs() nested iterate() function.

graphlog: implement --follow with file arguments

test-glog: test multiple --prune values

graphlog: restore FILE glob expansion on Windows On platforms not supporting shell expansion, scmutil.match() performs glob expansion on 'pats' arguments. But _matchfiles() revset calls match.match() directly, bypassing this behaviour. To avoid duplicating scmutil.match(), a secondary scmutil.matchandpats() is introduced returning both the match object and the expanded inputs. Note the expanded pats are also needed in the fast path, and will be used by --follow code path.

glog: restore multiple --rev test lost in rebasing

copies: remove checkdirs options This removes the undocumented merge.followdirs option, which has always been true.

copies: add docstring for mergecopies

addremove: return 1 if we failed to handle any explicit files

merge with stable

log: fix --follow FILE ancestry calculation Currently, --follow FILE looks for a FILE filelog, scans it and collects linkrevs and renames, then filters them. The problem is the filelog scan does not start at FILE filenode in parent revision but at the last filelog revision. So: - Files not in the parent revision can be followed, the starting node is unexpected - Files in the parent revision can be followed from an incorrect starting node. This patch makes log --follow FILE fail if FILE is not in parent revision, and computes ancestors of the parent revision FILE filenode.

test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.

graft: use proper revisions for copy detection (issue3265)

convert: fix typos in error messages

graphlog: paths/-I/-X handling requires a new revset The filtering logic of match objects cannot be reproduced with the existing revsets as it operates at changeset files level. A changeset touching "a" and "b" is matched by "-I a -X b" but not by "file(a) and not file(b)". To solve this, a new internal "_matchfiles(...)" revset is introduced. It works like "file(x)" but accepts more than one argument and its arguments are prefixed with "p:", "i:" and "x:" to be used as patterns, include patterns or exclude patterns respectively. The _matchfiles revset is kept private for now: - There are probably smarter ways to pass the arguments in a user-friendly way - A "rev:" argument is likely appear at some point to emulate log command behaviour with regard to filesets: they are evaluated for the parent revision and applied everywhere instead of being reevaluated for each revision.

graphlog: imitate log slowpath when inputs are explicit files

graphlog: paths arguments must be or'ed

graphlog: rewrite --rev like all other options

graphlog: --branch and --only-branch are the same Handling the aliasing in fancyopts would be cleaner but I do not want to make this change for stable.

test-check-code-hg: fix xargs exit status on OSX When xargs subcommand invocation fails in a normal way, GNU xargs returns 123 and BSD one returns 1.

largefiles: respect store.createmode and avoid extra file copy Before, a tempfile was used to create a temp file was created with 600 permissions and the uploaded data was written into it. This file was then *copied* to .hg/largefiles/<hash>. We now simply use atomictempfile to write the data to a temp file with the right permissions and then rename that into place.

largefiles: respect store.createmode in basestore.get This replaces another use of tempfile with atomictempfile. The problem with tempfile is that it creates files with 600 permissions instead of respecting repo.store.createmode.

largefiles: use repo.store.createmode for new files in .hg/largefiles Before, the mode was copied from the file in the working copy. This is inconsistent with how Mercurial normally creates files inside the .hg folder. This can lead to a situation where you can read the files under .hg/store but not under .hg/largefiles and so a clone will fail if it needs to access a largefile.

mq: expand qimport summary

merge with stable

graphlog: multiple --keyword must be or'ed

graphlog: multiple --branch must be or'ed

graphlog: multiple --user must be or'ed

graphlog: explicitely join multivalue parameters This will let use override the "join" value (and/or) depending on the option considered. The option revset arity is now deduced from the revset and the option value type, to simplify opt2revset definition.

test-glog.t: use printrevset extension to trace rewritten revsets Using "hg log -G --print-revset" prints the revset generated by graphlog and exits. This helps debugging and writing shorter tests. It has been suggested to handle these tests with doctests. I think the extension approach is better because: - It tests the actual parameter set passed to graphlog.revset(), not what we expect it to be. 'branch' and 'only-branch' are currently distinct options but nothing prevents fancyopts to grow a notion of option aliasing one day, where both options would be merged before reaching the command. - It can be used as debug output interleaved with real log calls. v2: - Use a test extension instead of a global deprecated new option

context: use 'changectx.dirs()' in 'walk()' for directory patterns this patch uses 'changectx.dirs()' instead of nested loop, to examine whether specified pattern is related to the context as a directory or not.

localrepository: use 'changectx.dirs()' in 'status()' for directory patterns when pattern which does not match against any files in working context is specified, current implementation of 'localrepository.status()' decides whether warning message about it should be shown or not by 'f not in context' this works correctly for 'file pattern', but not for 'directory pattern', because 'f not in context' always returns True for directories, even if they are related to the context. this patch uses 'changectx.dirs()' to examine whether specified pattern is related to the context as a directory or not.

context: add 'dirs()' to changectx/workingctx for directory patterns this patch adds 'dirs()' to changectx/workingctx, which returns map of all directories deduced from manifest, to examine whether specified pattern is related to the context as directory or not quickly. 'workingctx.dirs()' uses 'dirstate.dirs()' rather than building another copy of it.

status: fix format field thinko

largefiles: don't break filesets

help: sort hgrc related "Sections" chapters alphabetically

doc: minor fixes to [graph] section documentation

hgweb: refactor graph customization javascript - Avoid flipping lineWidth state around the edge() call, pass it to the function instead. - Pass the line width and color appended to the other parameters instead of in a dictionary. The javascript code is simpler, no need to check for all containers existence, and the JSON output is smaller. - Reindent setColor() comments and fix code spacing.

templates: move Graph.edge() implementation in mercurial.js All implementation in graph.tmpl are the same. It can still be overriden if necessary. There is no clear reason to keep it separated from mercurial.js.

formatter: convert status command

ui: add formatter method

formatter: add basic formatters

encoding: introduce utf8-b helpers

graphmod: add config cache Before, we'd lookup the branch for every edge segment in the entire graph: extremely expensive. This happened even when no per-branch settings existed. Now we define a revision -> config cache function that's LRU-cached and is a no-op when no configuration exists. Still not terribly fast, but hopefully only one real branch lookup per revision. This might degenerate for wide graphs as the LRU is hard-coded to 20 elements.

graphmod: rewrite graph config validation Our goal is not to strictly disallow _invalid_ input, simply disallow _hostile_ input. Avoid using re Avoid creating empty dicts when no branch parameters are recognized

graph: in hgrc specify line color for main branch You can specify color to visually distinguish main branch (trunk) on hgweb's graph page. If color specified, all branch heads will share same color. Settings format is branch_name.color = value, where color is six hexadecimal digits e.g.: [graph] default.color = FF0000

graph: in hgrc specify line width for main branch You can specify width to visually distinguish main branch (trunk) on hgweb's graph page. Settings format is branch_name.width = value, where width in px e.g.: [graph] default.width = 3

merge with stable

filemerge: remove some redundancy in decorators/docstrings

filemerge: create detail of internal merge tools from documentation string this patch introduces 'internaltoolsmarker' which creates detail of each internal merge tools from documentation string for 'hg help merge-tools'.

filemerge: refactoring of 'filemerge()' current 'filemerge.filemerge()' implementation is verfy complicated. - it is not easy to add new internal merge tools (only by patching on 'filemerge()', or replacing it completely) - cleanup of temporary files is unsatisfactory ('internal:dump' does not, in fact) this is patch for refactoring of 'filemerge()' to isolate each internal merge tool implementations from 'filemerge()', and clean up common part in it.

patch: fuzz more aggressively to match patch(1) behaviour The previous code was assuming a default context of 3 lines. When fuzzing, it would take this value in account to reduce the amount of removed line from hunks top or bottom. For instance, if a hunk has only 2 lines of bottom context, fuzzing with fuzz=1 would do nothing and with fuzz=2 it would remove one of those lines. A hunk with one line of bottom context could not be fuzzed at all. patch(1) has apparently no such restrictions and takes the fuzz level at face value. - test-import.t: fuzz/offset changes at the beginning of file are explained by the new fuzzing behaviour and match patch(1) ones. Patching locations are different but those of my patch(1) do not make a lot of sense right now (patched output are the same) - test-import-bypass.t: more agressive fuzzing makes a patching supposed to fail because of context, succeed. Change the diff to avoid this. - test-mq-merge.t: more agressive fuzzing would allow the merged patch to apply with fuzz, but fortunately we disallow this behaviour. The new output is kept. I have not enough experience with patch(1) fuzzing to know whether aligning our implementation on it is a good or bad idea. Until now, it has been the implementation reference. For instance, "qpush" tolerates fuzz (test-mq-merge.t runs the special case of pushing merge revisions where fuzzing is forbidden).

patch: fix fuzzing of hunks without previous lines (issue3264) When applying hunks such as: @@ -2,1 +2,2 @@ context +change fuzzing would empty the "old" block and make patchfile.apply() traceback. Instead, we apply the new block at specified location without testing. The "bottom hunk" test was removed as patch(1) has no problem applying hunk with no context in the middle of a file.

patch: make hunk.fuzzit() compute the fuzzed start locations - It moves hunks processing weirdness where it belongs - It helps reusing said weirdness whenever fuzzit() is called, like during the actual hunk fuzzing.

patch: fuzz old and new lines at the same time In theory, the fuzzed offsets for old and new lines should be exactly the same as they are based on hunk parsing. Make it true in practice.

largefiles: optimize update speed by only updating changed largefiles Historically, during 'hg update', every largefile in the working copy was hashed (which is a very expensive operation on big files) and any largefiles that did not have a hash that matched their standin were updated. This patch optimizes 'hg update' by keeping track of what standins have changed between the old and new revisions, and only updating the largefiles that have changed. This saves a lot of time by avoiding the unecessary calculation of a list of sha1 hashes for big files. With this patch, the time 'hg update' takes to complete is a function of how many largefiles need to be updated and what their size is. Performance tests on a repository with about 80 largefiles ranging from a few MB to about 97 MB are shown below. The tests show how long it takes to run 'hg update' with no changes actually being updated. Mercurial 2.1 release: $ time hg update 0 files updated, 0 files merged, 0 files removed, 0 files unresolved getting changed largefiles 0 largefiles updated, 0 removed real 0m10.045s user 0m9.367s sys 0m0.674s With this patch: $ time hg update 0 files updated, 0 files merged, 0 files removed, 0 files unresolved real 0m0.965s user 0m0.845s sys 0m0.115s The same repsoitory, without the largefiles extension enabled: $ time hg update 0 files updated, 0 files merged, 0 files removed, 0 files unresolved real 0m0.799s user 0m0.684s sys 0m0.111s So before the patch, 'hg update' with no changes was approximately 9.25s slower with largefiles enabled. With this patch, it is approximately 0.165s slower.

mq: make qimport --push push all imported patches (issue3130) Only the first imported one was pushed.

convert: tolerate spaces between splicemap parent ids (issue3203) Splicemap lines are documented in hg help convert like: key parent1, parent2 but parsed like: key, parents = line.strip().rsplit(' ', 1) parents = parents.replace(',', ' ').split() The rsplit() call was introduced to handle spaces in keys for the generic mapfile format. Spaces can appear in svn identifiers since they contain path components. This logic makes less sense with splicemap since svn identifiers can also appear on the right side, even if it is a bit less likely. Given the parsing is theorically broken, I would rather follow what is documented already and is correct in the main case where all identifiers are hg hashes. Also, using svn identifiers in a splicemap sounds difficult as they are not easily accessible.

test-commandserver: flush stdout

localrepo: clear _filecache on rollback (issue3261) Files are being replaced by rollback but the corresponding data in localrepo isn't actually updated for things like bookmarks, phases, etc. Then when rollback is done, the cache is updated thinking it has the most up-to-date data, where in fact it is still pre-rollback. We clear _filecache to force everything to be recreated.

scmutil: update cached copy when filecached attribute is assigned (issue3263) When assigning a new object to filecached properties, the cached object that was kept in the _filecache map was still holding the old object. By implementing __set__, we track these changes too and update the cached copy as well.

cmdserver: invalidate the dirstate when running commands (issue3271) The dirstate is invalidated separately outside of invalidate() which is already being called (other callers of invalidate() seems to suggest the separation is there for a reason).

localrepo: reset _phasesdirty flag after writing

import: handle git renames and --similarity (issue3187) There is no reason to discard copy sources from the set of files considered by addremove(). It was done to handle the case where a first patch would create 'a' and a second one would move 'a' to 'b'. If these patches were applied with --no-commit, 'a' would first be marked as added, then unlinked and dropped from the dirstate but still passed to addremove(). A better fix is thus to exclude removed files which ends being dropped from the dirstate instead of removed. Reported by Jason Harris <jason@jasonfharris.com>

context: make workingctx.forget() really warn about untracked files

largefiles: check whether specified patterns are related to largefiles strictly current 'lfiles_repo.status()' implementation examines whether specified patterns are related to largefiles in working directory (not to STANDIN) or not by NOT-EMPTY-NESS of below list: [f for f in match.files() if f in lfdirstate] but it can not be assumed that all in 'match.files()' are file itself exactly, because user may only specify part of path to match whole under subdirectories recursively. above examination will mis-recognize such pattern as 'not related to largefiles', and executes normal 'status()' procedure. so, 'hg status' shows '?'(unknown) status for largefiles in working directory unexpectedly. this patch examines relation of pattern to largefiles by applying 'match()' on each entries in lfdirstate and checking wheter there is no matched entry. it may increase cost of examination, because it causes of full scan of entries in lfdirstate. so this patch uses normal for-loop instead of list comprehensions, to decrease cost when matching is found.

merge with stable

log: remove caching of all visited revisions (issue3253) Not only does this eat all available memory for some users, it's slower.

pull: backout change to return code This bit a number of people.

convert: use splicemap entries when sorting revisions (issue1748) When sorting revisions before converting them, we have to edit the revision graph using splicemap entries. Otherwise, a spliced revision may be converted before its synthetic parents. Invalid splicemap revisions are now detected before starting the conversion.

convert: turn splicemap into a simple dictionary Parsing the splicemap as a mapfile was a pain because map does not let us override its parsing code and splicemap entries are not key/values. Besides we had no need for mapfiles extra features. Just parse the splicemap and return a dictionary.

debugrevspec: mention --verbose to print the parsed tree

largefiles: only cache largefiles in new heads This fixes a serious performance regression in largefiles introduced in Mercurial 2.1. Caching new largefiles on pull is necessary, because otherwise largefiles will be missing (and unable to be downloaded) when the user tries to merge or rebase a new head with an old one. But this is an expensive operation and should only be done for heads that are new from the pull, rather than on all heads in the repository.

merge with stable

mq: restore _branchtags() fast path (issue3223) Since a5917346c72e, mq saves the nodeid of the first applied patch to cache/branchheads, which breaks the optimized cache handling introduced in fbf8320f25c8. The problem is the revision being committed is appended to mqrepo.applied after the commit succeeds, which means mqrepo._branchtags() performs a regular update and write the first applied patch to the branch cache. One solution is to set a context variable _committingpatch on the mqrepo while it is committing a patch and to take it in account when deciding to fast-path mqrepo._branchtags(). Not really elegant but it works. The changes to test-mq-caches.t reverse changes introduced by a5917346c72e. The cache should not have been updated with mq records. The changes to test-keyword.t are indirectly caused by a5917346c72e. Reported and analyzed by Yuya Nishihara <yuya@tcha.org> Notes: - qpush still makes a slow path _branchtags() call when checking heads. Maybe this can be optimized. - be careful when merging this patch in default as secretcommit() was renamed newcommit() right after the end of the code freeze.

mq: ensure all mq commits are made with secretcommit() Having a common code path helps fixing things globally.

convert/bzr: ignore nested repos when listing branches (issue3254) Reported by A.S. Budden <abudden@gmail.com>

tests: tighten checks for octal escapes in shell printf. printf on AIX default shell ksh (89) says \1 is an invalid escape. It insists on at least 2 digits. This causes failures in test-keyword.t and test-status.t. check-code.py already looks out for \NNN and recommends using Python for outputting octal values. Extend the check to \NN and \N and fix up resulting failures.

phase: when phase cannot be reduced, hint at --force and return 1 (BC) Before, trying to change the phase of a "public" node to "draft" would result in: $ hg phase --draft . no phases changed [0] With this patch: $ hg phase --draft . cannot move 1 changesets to a more permissive phase, use --force no phases changed [1] On partial failures, the exit status is now 1 instead of 0 and the number of changed nodes is displayed while it was only with --verbose. It seems useful to tell the user that despite the apparent failure, something changed. $ hg phase --draft '5 or 7' cannot move 1 changesets to a more permissive phase, use --force phase changed for 1 changesets [1]

revset: fix alias substitution recursion (issue3240) The revset aliases expansion worked like: expr = "some revset" for alias in aliases: expr = alias.process(expr) where "process" was replacing the alias with its *unexpanded* substitution, recursively. So it only worked when aliases were applied in proper dependency order. This patch rewrites the expansion process so all aliases are expanded recursively at every tree level, after parent alias rewriting and variable expansion.

update: just merge unknown file collisions The unknown file collision rule was introduced as an extension of the "should be clean when merging" rule. Unfortunately, it got applied to the normal update path, which should be happy to merge local changes. This patch gives us merges for unknown file collisions on update, while preserving abort for merge and update -c.

merge: don't use unknown() This removes use of unknown files for building the synthetic working directory manifest used by manifestmerge. Instead, we adopt the strategy used by _checkunknown. Side-effect: unknown files are no longer moved by remote directory renames, and now are left alone like ignored files.

merge: refactor unknown file conflict checking Previously, we would do a full working directory walk including unknown files to perform a merge. In many cases, this was painful because unknown files greatly outnumbered tracked files and generally had no useful effect on the merge. Here we instead wait until we find a file in the destination that's not tracked locally and detect if it exists and is not ignored. This is usually cheaper but can be -more- expensive in the case where we're adding a huge number of files. On the other hand, the cost of statting the new files should be dwarfed by the cost of eventually writing them. In this version, case collisions are detected implicitly by os.path.exists and wctx[f] lookup.

update: use normal update path with --check (issue2450) This avoids clobbering unknown files on update by not using overwrite mode.

fetch: use update rather than clean when updating (issue3246) We already verify the working directory is "clean" before starting so there's no advantage to clobbering the working directory.

merge with stable

mdiff: adjust hunk offsets with --ignore-blank-lines (issue3234) When diffing the following documents with --ignore-blank-lines (-B): $ cat > a <<EOF > > > > b > x > d > EOF and: $ cat > b <<EOF > b > y > d > EOF the context lines are taken from the first document, even if the lines differ (with -w or -b) or if the number of lines differ (with -B). In the second case, we have to adjust the hunk new lines offsets or we end with inconsistent diffs like (see the @@ offsets): diff -r 0e66aa54f318 a --- a/a +++ b/a @@ -1,4 +1,3 @@ b -x +y d Note that having different context lines in a and b means the diff can be applied but is not invertible. Reported by Nicholas Riley <com-selenic@sabi.net>

merge with stable

merge with i18n

merge with i18n

i18n-de: fix rst markup in command output (issue3247)

merge with i18n stable

i18n-ru: fix hg command rst markup

i18n-ja: fix rst markup in hg command output

i18n-de: fix rst markup in command output (issue3247)

merge with i18n stable

i18n-de: fix hg command rst markup and quoting (issue3247)

merge with i18n stable

i18n-de: fix rst markup in command output (issue3247)

windows: use 'str.replace()' instead of combination of split() and join() 'str.replace()' is twice (or more) as fast as combination of split() and join(). combination of split() and join() in current 'util.pconvert()' implementation comes only from historical reason when win32mbcs extension was introduced.

largefiles: reduce redundant splitstandin/standin combination assumptions: - 'lfutil.splitstandin(f)' strips 'f' of '.hglf/', if it can - 'lfile(f)' examines 'lfutil.standin(f) in manifest' - 'lfutil.standin(f)' adds '.hglf/' to 'f' and - 'f' should start with '.hglf/' there, because it is already examined by 'lfutil.isstandin(f)' then: lfile(lfutil.splitstandin(f)) => lfile(<f without '.hglf/'>) => lfutil.standin(<f without '.hglf/'>) in manifest => <<f without '.hglf/'> with '.hglf/'> in manifest => f in manifest

largefiles: reduce OR-ing of same conditions

subrepo: rewrite handling of subrepo state at commit (issue2403) When the contents of .hgsubstate are stale (either because they've manually been tweaked or partial updates have confused it), we get confused about whether it actually needs committing. So instead, we actively consult the parent's substate and compare it the actual current state when deciding whether it needs committing. Side effect: lots of "committing subrepo" messages that didn't correspond with real commits disappear. This change is fairly invasive for a fairly obscure condition, so it's kept on the default branch.

subrepo: add basestate method This will allow us to sort out what's going on with state .hgsubstate files more precisely.

bdiff: fix malloc(0) issue in fixws() If fixws() is called on a zero-length string, malloc(0) is called and expected to return a pointer. Which it does on e.g. Linux. AIX returns NULL, which it is also legal, but the malloc() is then assumed to have failed. So ensure a valid pointer is always returned.

forget: show warning messages for forgetting in subrepo correctly in 'cmdutil.forget()': for f in match.files(): if match.exact(f) or not explicitonly: .... is equal to: for f in match.files(): if True: .... because 'f' from 'match.files()' should 'match.exact(f)': - 'match.files()' returns 'self._files' - 'match.exact(f)' examines 'f in self._fmap', - 'self._fmap' of match is 'set(self._files)' then, 'explicitonly' wants to suppress warning messges, if it is true (= 'cmdutil.forget()' is invoked from 'subrepo.forget()'). so, current code should be fixed as: if not explicitonly: for f in match.files(): ....

tests: fix command line overflow on ksh "<command> `hg manifest`" overflows the puny 1024 byte command line length limit on AIX default shell ksh. Replace with "hg manifest | xargs <command>".

use util.localpath() instead of 'str.replace()' to unify path conversion

i18n: use util.pconvert() instead of 'str.replace()' for problematic encoding some problematic encodings use backslash as part of multi-byte characters. util.pconvert() can treat strings in such encodings correctly, if win32mbcs is enabled, but str.replace() can not.

i18n: use util.pconvert() instead of 'str.replace()' for problematic encoding some problematic encodings use backslash as part of multi-byte characters. util.pconvert() can treat strings in such encodings correctly, if win32mbcs is enabled, but str.replace() can not.

merge with stable

mq: make qprev return the previous applied patch (issue3245) The current behaviour is to return the previous one in the series but at the same time the implementation is buggy because it does not take guarded patches in account.

mq: fix qnext when all remaining patches are guarded When all remaining patches are guarded, qnext used to return the last of the queue anyway.

convert/bzr: test tags conversion

convert/bzr: handle empty bzr repositories (issue3233)

convert/bzr: convert all branches (issue3229) (BC) Instead of opening the target bzr checkout as a single branch, we try to open it as a repository. This has the following effects: - All branches are now converted - bzr branch names are preserved. Previously, the selected branch was always converted as 'default'. Branches without a name or 'trunk' are mapped to 'default branch. - Lightweight checkouts are no longer supported. Maybe they can be, I did not try to fix that at all. Implementation notes: - This was a quick fix, I have no knowledge of bzr API besides browsing 2.0.3 sources. - The fix was only tested on OSX against bzr 2.4.2. - Tags discovery does not handle collisions. I have no idea how tags work in bzr so maybe such collisions are not possible.

convert/bzr: expect unicode metadata, encode in UTF-8 (issue3232) Before this patch, metadata and file names were interpreted like: - unicode objects were converted to UTF-8 - non unicode objects were left unchanged Looking at the code and bzr being known for transcoding filenames, we expect everything to be returned as unicode objects, and we want to encode them in UTF-8, like the subversion source does. To do that, we just remove the custom implementation of .recode().

test-mq: fix sed call on OSX - The regular sed on OSX wants: -i "" not -i"" - GNU sed wants: -i"" not -i "" Backups are fine.

mq: rename secretcommit to newcommit This function create secret changeset only when mq.secret is true

merge with stable

i18n-de: update po and remove fuzzies

i18n-de: Rework and fixes continued

Added signature for changeset 2aa5b51f310f

Added tag 2.1 for changeset 2aa5b51f310f

phases: don't complain if cset is already public on pushkey (issue3230)

i18n-pt_BR: synchronized with 140b6282ac79

merge with i18n

mq: prevent rewriting operation on public changeset The following operation are denied if the mq changeset is public * qrefresh * qpop * qfold note: qimport was already denied.

i18n-pt_BR: miscellaneous spelling and wording fixes

i18n-ja: synchronized with 0f99e709ce08

i18n-ru: synchronized with c0b2986b37b8; public phase name changed

i18n-pt_BR: synchronized with c0b2986b37b8

qpush: avoid trying to manage existing history (issue2218)

bundlerepo: try to find containing repo on creation (issue1812)

phases: add resync example to help topic

mq: fix secret description in help

pull: return 1 when no changes found (BC) Currently we have the following return codes if nothing is found: commit incoming outgoing pull push intended 1 1 1 1 1 documented 1 1 1 0 1 actual 1 1 1 0 1 This makes pull agree with the rest of the table and makes it easy to detect "nothing was pulled" in scripts.

push: don't treat bookmark as a found change Treating bookmarks as a found change results in confusing documentation or output and is less useful for scripting.

glossary: add phase terms

merge with i18n

i18n-sv: snchronized with ed9f40bc346f

i18n-ru: phases help translated

i18n-ru: minor corrections on unclear strings

i18n-ru: synchronized with 2605fc990725

i18n-ru: verifying uncertain translations.

phases: allow phase name in phases.new-commit settings Before this commit only phase index where accepted

qfinish: do not set secret changeset to draft if mq.secret=false If mq.secret=false, mq should not touch phase

mq: take mq.secret configuration into account when picking the default phase

qimport: when mq.secret=True set qimported revision as secret

qrefresh: keep changeset phase during refresh

phases: write default phase data as soon as possible. Marks phase data as dirty when computing default phase. Actual writing is done when the lock is released. So, read only operation don't write phase data because they don't lock the repo.

phase: accept old style revision specification

push: return 1 if no changes found (issue3228) Currently we have the following return codes if nothing is found: commit incoming outgoing pull push intended 1 1 1 1 1 documented 1 1 1 0 1 actual 1 1 1 0 0 This fixes the lower-right entry.

push: more precise failure check on subrepo push This will let us distinguish between nothing to push and push failed

push: return 0 when updating bookmarks

push: fix coding errors in unused branch This branch will get re-enabled in a subsequent fix

bookmarks: move current bookmark on update -u and bare pull -u (issue3222) Currently, this won't update when a #branch spec is in the URL

phases: fix verify with secret csets Verify uses repo.cancopy() to detect whether a repo is a plain old local repo, so it was giving a confusing error message when secret changesets were present.

mq: add secret setting

merge with i18n

i18n-pt_BR: synchronized with f2c49d9dee57

tests: don't rely on 'false' exit code in test-run-tests.t On Solaris: $ sh -c 'false ; echo $?' 255

tests: don't use alias alias doesn't work in Solaris sh.

tests: don't include plain 'diff -U0' content in test-diff-unified.t The only purpose of 'diff -U0' was to show that 'hg diff -U0' did almost the same. Unfortunately 'diff -U0' on Solaris gives incorrect line numbers. Masking it with globs wouldn't it make sense, so removing it is the best solution.

help: add examples to phases topic

update: note updated bookmark This brings update in line with pull: we notify the user when an action indirectly updates a bookmark.

resolve: mention merge-tools topic in help

revset: add tests for 'remote()' predicate

revset: fix documentation for 'remote()' predicate current documentation for 'remote()' predicate is wrong about specification of parameters. there are 3 patterns: # of param: id: remote: - 0 current branch "defult" remote - 1 specified "defult" remote - 2 specified specified

revset: fix 'remote()' failure when remote repo has more revs than local current 'remote()' implementation uses 'r' variable, even if it is not initialized when 'if n in repo' is not true. this causes unexpected exception.

help/config: fix help command markup

merge with i18n

i18n-ru: synchronized with bf502ccc46d7; fuzzies removed

i18n-ru: fix typos in `resolve` help * help entry is called 'merge-tools', not 'merge-tool'; * envvar is called HGMERGE, not HGEMERGT.

merge: defer symlink flag merging to filemerge (issue3200) Previously, we could change a normal file into a corrupt symlink when trying to merge a symlink flag. Now, we leave the flag alone and let filemerge deal with it (usually by a prompt). We also drop a redundant flag setting after filemerge (now dealt with by ms.resolve) that would cause similar corruption.

help: fix publish option spelling in phases topic

help: add missing phase config items to config topic

help/phases: remove trailing whitespace

sslutil: more helpful fingerprint mismatch message This will aid debugging for users of sites that renew certs.

help: add phases topic

i18n-pt_BR: synchronized with 0b05e0bfdc1c

copies: remove stray print

scmutil: unify some 'no changes found' messages This keeps the wording more consistent for secret csets

outgoing: display info about secret changets while no sharable changeset found

bundle: display info about secret changets while no sharable changeset found

test-rebase-collapse: Add test for rebase regression introduced in 12309c09d19a

test-commandserver: test that phase data is being refreshed

localrepo: delete _phaserev when invalidating caches

localrepo: fix phaseroots filecache definition it's in .hg/store

discovery: fix regression when checking heads for pre 1.4 client (issue3218) This code is not run by the test suite and silly name error were lurking here.

help: mark strings for translation

bookmarks: respect --debug during incoming/outgoing

largefiles: fix revert on missing largefile (issue3217)

largefiles: fix transplant for all cases (issue3192)

i18n-ru: synchronized with 9f2ed48f8cda

i18n-sv: translated phase

i18n-sv: translating strings for add, annotate, debuginstall

i18n-sv: synchronized with c2e6c5ef4555

merge with i18n

copies: eliminate criss-crosses when chaining Before the copies refactoring, we declared that if a and b were present in source and destination, we ignored copies between them. The refactored code could however report b was a copy of a and vice versa in a situation where we looked for differences between two identical changesets that copy a to b. y / x \ y'

i18n-pt_BR: synchronized with f7c8d6ee6056

merge with i18n

i18n-sv: synchronized with 7ed056f1e97d

mq: pass qbase node instead of mq statusentry in phasedefaults This was breaking my remotebranches extension in a completely mystifying way, because repo.lookup was failing to resolve the statusentry. I'm not sure how this works absent my remotebranches extension, but doing it this way looks more correct and doesn't break anything.

patch: a little bit more robust line counting on diff --stat (issue3183)

convert: subversion convert abort on revision not found (issue 3205)

bash_completion: added -o filename option to _hg_status (issue3101)

phase: alway return a value With the previous code, the phase command was returning None when displaying phase and 0 or 1 when moving them. This seemed an bit odd and displaying phase return 0 too now.

largefiles: fix addremove when no largefiles are specified

revset: include the correct first ancestor change for follow(file) Previously we always included '.', which may not touch a file. Instead, find the file revision present in '.' and add its linkrev. This matches the results of 'hg log --follow file'.

revset: remove unreferenced followfile function

revsets: provide contexts for filesets Before this change, revsets containing fileset patterns failed. This allows queries like: hg log -r "contains('set: added() and symlink()')"

fileset: don't attempt to check data predicates against removed files

revset: simplify help not about quoting

Added signature for changeset db33555eafea

Added tag 2.1-rc for changeset db33555eafea

bookmarks: correct correction of -i

commands: drop exclamation mark in abort message

update: note ways to avoid moving bookmark

push: prevent moving phases outside of the pushed subset

discovery: ensure that missingheads are always heads of everything we tried This only alter the third block executed when: * repo have secret changeset * onlyheads is not None In other case findcommonoutgoing already had this behavior

phase: extracts heads computation logics from analyzeremotephases

phase: fix warning text from invalid remote phase add missing end of line and substitution.

mq-safety: don't apply safety on non-outgoing changeset When mq changeset are secret, they don't appear in outgoing and won't be pushed. So it's not necessary to abort the push. The checkpush call is protected by lock to prevent race on phase.

phases: properly register excluded changeset when revision are specified There was no other drawback than a bad UI message for now.

bookmarks: make -i summary simpler and more accurate