help/config: remove outdated false claim about pywin32 Since version 1.8 (released on 2011-03-01), Mercurial doesn't use pywin32 any more. The old fallback mechanism to use C:\Mercurial\Mercurial.ini if pywin32 is not installed was removed in 244772f67ac1.

merge with stable

revert: don't re-create changeset context

factotum: add man reference to help output

test-largefiles: better formatting of comments

test-largefiles: sort output to ensure test stability

merge with stable

largefiles: make archive -S store largefiles instead of standins This is essentially a copy of largefile's override of archive() in the archival class, adapted for overriding hgsubrepo's archive(). That means decoding isn't taken into consideration, nor is .hg_archival.txt generated (the same goes for regular subrepos). Unlike subrepos, but consistent with largefile's handling of the top repo, ui.progress() is *not* called. This should probably be refactored at some point, but at least this generates the archives properly for now. Previously, the standins were ignored and the largefiles were archived only for the top level repo. Long term, it would probably be most desirable to figure out how to tweak archival's archive() if necessary such that largefiles doesn't need to override it completely just to special case the translating of standins to the real files. Largefiles will already return a context with the true largefiles instead of the standins if lfilesrepo's lfstatus is True- perhaps this can be leveraged?

paper, monoblue: link correctly to lines in annotate view The links were to "foo#123" instead of "foo#l123". The gitweb and spartan templates were already producing the correct links.

merge with stable

Added signature for changeset 5983de86462c

Added tag 2.2.1 for changeset 5983de86462c

bookmarks: catch the proper exception for missing revisions This fixes a regression from 1.7

parsers: fix refcount leak, simplify init of index (issue3417) This is most easily verified using valgrind on a long-running process, as the leak has no visible consequences during normal one-shot command usage. In one window: valgrind --leak-check=full --suppressions=valgrind-python.supp \ python ./hg serve In another: for ((i=0;i<100;i++)); do curl -s http://localhost:8000/file/tip/README >/dev/null done valgrind should report no leaks.

largefiles: fix commit of both largefiles and non-largefiles (issue3354) This bug was caused by some old code that should have been removed long ago.

help: added description for the web.collapse setting The collapse configuration setting for hgweb was recently introduced, but the help text was unfortunately omitted from the patch concerned. This patch provides a suitable help text.

merge with stable

help: add reference to template help (issue3413) There is currently no clear link between the help for log and the help on templates. The log option is --template but the template help is 'help templating' or 'help templates'. This patch makes 'hg help template' work and also adds a note into the log help explaining where to find more info.

patch: clarify binary hunk parsing loop

rebase: make --dest understand revsets

rebase: add missing EOL to debug strings

merge with stable

Added signature for changeset 00182b3d0879

Added tag 2.2 for changeset 00182b3d0879

i18n-ja: synchronized with f2a3ce017355

i18n-pt_BR: synchronized with 517b25608ad6

merge with i18n

i18n-ja: synchronized with be786c5ac0a8

changegroup: decompress GZ algorithm in larger chunks for better performance

plan9: mkfile and 9diff fixes This patch deals with an unnecessary backslash in 9diff and improper quoting in the contrib mkfile.

subrepo/svn: cache _wcrev() value in merge()

subrepo/svn: fix checked out rev number retrieval (issue2968) The initial version was to take the "Revision" field from svn info. It works but produces false positive when parent paths are being moved or unrelated changes are being committed, causing it to change while the svn checkout itself remains the same. To avoid spurious commit, we took "Revision" and "Last Changed Rev" for general comparison and kept the latter to answer "what is your revision?" question. This is better but fails when the subrepo path exists at "Revision" but not at "Last Changed Rev". This patch adds a check for this, and returns "Revision" if the path does not exist. We try to avoid doing this as much as possible at it implies an extra, *remote* call.

amend: fix copy records handling (issue3410) Messing with the dirstate before the intermediate commit seems error prone. Instead, commit and recompute the copies with copies.pathcopies(), then use that with commitctx(). Since copies.pathcopies() does not support file replacement very well, the whole .renamed() condition in samefile() is removed and the "file replacement caused by differing copy source" effect is discarded. Test shamelessly stolen from Idan Kamara <idankk86@gmail.com>

test-commit-amend: exhibit an --amend weirdness The weirdness is --amend let you replace one file with another with same data and flags if the new file copy record differ from the one in the parent revision. In theory, there is no problem with this kind of thing, subversion supports it, but here we see log and status disagree. The reason is log reads the copy record from the filelog, while status calls copies.pathcopies() which eventually invokes some expensiveness argument to discard this case (copies.py, _forwardcopies(), line 132). Since the next patch will side with pathcopies(), I prefer to call this behaviour a bug.

localrepo: add setparents() to adjust dirstate copies (issue3407) The fix introduced in eab9119c5dee was only partially successful. It is correct to turn dirstate 'm' merge records into normal/dirty ones but copy records are lost in the process. To adjust them as well, we need to look in the first parent manifest to know which files were added and preserve only related records. But the dirstate does not have access to changesets, the logic has to moved at another level, in localrepo.

test-rebase-parameters: more tests for revset/opts - --source and revset - --base and revset - --rev and revset - --rev and --source combination - --rev and --base combination

help/config: expand [subpaths] help Brifly explain why rewriting subrepository paths can be necessary. Explain that relative subrepository paths are made absolute before rewrite rules are applied.

doc: update copyright years to 2012 I sometimes look at a piece of software and if the man page says "Copyright 2004", then I'm inclined to think that the project is stale or that the authors are lazy. Neither is good publicity for us :-)

help: consistently use title capitalization for help topics

merge with i18n

i18n-pt_BR: synchronized with e37199a1f9d4

merge with i18n

i18n-ja: synchronized with 4bce649a2b0f

dirstate: preserve path components case on renames (issue3402) The original issue was something like: $ hg init repo $ cd repo $ mkdir D $ echo a > D/a $ hg ci -Am adda adding D/a $ mv D temp $ mv temp d $ echo b > d/b $ hg add d/b adding D/b $ hg ci -m addb $ hg mv d/b d/c moving D/b to d/c $ hg st A d/c R D/b Here we expected: A D/c R D/b the logic being we try to preserve case of path components already known in the dirstate. This is fixed by the current patch. Note the following stories are not still not supported: Changing directory case $ hg mv D d moving D/a to D/D/a moving D/b to D/D/b $ hg st A D/D/a A D/D/b R D/a R D/b or: $ hg mv D/* d D/a: not overwriting - file exists D/b: not overwriting - file exists And if they were, there are probably similar issues with diffing/patching.

tests: quote dummyssh in a way that works on windows too Don't depend on $environmentvariableexpansion and 'quote' handling in system()

tests: add missing accept of native pathname separator

tests: skip new tests with requirements not available on windows

tests: don't require 'hg' without extension on windows Hackable uses hg.exe instead.

update .hgignore for hackable with Python 2.7

commit: abort on merge with missing files Here is a script illustrating the previous behaviour: The merge brings a new file 'b' from remote $ hg merge 1 --debug searching for copies back to rev 1 unmatched files in other: b resolving manifests overwrite: False, partial: False ancestor: 07f494440405, local: 540395c44225+, remote: 102a90ea7b4a b: remote created -> g updating: b 1/1 files (100.00%) getting b 1 files updated, 0 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) Delete but do not remove b $ rm b $ hg st ! b The commit succeeds $ hg commit -m merge $ hg parents --template "{rev} {desc|firstline} files: {files}\n" 3 merge files: $ hg st ! b b changes were ignored, but even b existence was ignored $ hg manifest a This happens because localrepo.commitctx() checks the input ctx.files(), which is empty for workingctx.files() only returns added, modified or removed entries, and bypass files/manifest updates completely. So the committed revision manifest is the same as its first parent one, not containing the 'b' file. This patch forces the commit to abort in presence of a merge and missing files. test-merge4.t is modified accordingly as it was introduced to check hg was not just terminating with a traceback (5e9e8b8d2629).

branchmap: server should not advertise secret changeset in branchmap (Issue3303) Discovery now use an overlay above branchmap to prune invisible "secret" changeset from branchmap. To minimise impact on the code during the code freeze, this is achieve by recomputing non-secret heads on the fly when any secret changeset exists. This is a computation heavy approach similar to the one used for visible heads. But few sever should contains secret changeset anyway. See comment in code for more robust approach. On local repo the wrapper is applied explicitly while the wire-protocol take care of wrapping branchmap call in a transparent way. This could be unified by the Peter Arrenbrecht and Sune Foldager proposal of a `peer` object. An inappropriate `(+i heads)` may still appear when pushing new changes on a repository with secret changeset. (see Issue3394 for details)

merge: check for untracked files more precisely (issue3400) This fixes the regression, but still leaves the long-standing issue that merge doesn't cope with trying to merge files and directories.

revlog: backout e5750c6716eb This regresses performance of 'hg branches', presumably because it's visiting the revlog in the wrong order. This suggests we either need to fix the branch code or add some read-behind to mitigate the effect.

wireprotocol: use visibleheads as reference while unbundling (issue 3303) The `repo` object here is *always* local. Using `repo.heads()` ensure we will reject push if any secret changeset exists. During discovery, `visibleheads` were sent to the peer. So we can only expect it to send us `visibleheads` back. If any secret changeset exists:: visibleheads != repo.heads() This fix server side part of issue 3303 when pushing over the wire.

rebase: preserve mq series order, guarded patches (issue2849) The previous code was rebasing an applied series like: patch1 +guarded patch2 patch3 +guarded patch4 patch5 +guarded into: patch2 patch4 patch1 +guarded patch3 +guarded patch5 +guarded Reported by Lars Westerhoff <lars.westerhoff@newtec.eu> Also rename mq.series_dirty into mq.seriesdirty, missed by 599a72895c0d, and without effect since mq.qimport() was setting it already.

subrepo/svn: improve error message on missing files From: abort: failed to commit svn changes to: abort: cannot commit missing svn entries

subrepo/svn: abort on commit with missing file (issue3029) Previous code was printing a traceback because it expected some error output from svn. But sometimes our definition of "changed" differs with the subversion one. For instance, subversion ignores missing files when committing. And when there are only missing files, svn commit will be a successful no-op with no output. Still, we should stick to our definition including missing files in changes as doing otherwise could cause surprising behaviour for the user.

doc: flatten description of 'matching()' predicate to be formatted well current description of 'matching()' revset predicate can't be formatted well on "hg help revset" output. each descriptions for revset predicates (or something like them) are split-ed into lines, and spaces on left side of them are stripped before minirst processing. so, bullet list can't be nested. this patch just flattens description of 'matching()' predicate to be formatted well.

subrepo: fix default implementation of forget() (issue3404)

test-subrepo-svn: fix non-determinism The test was randomly failing with: --- /tests/test-subrepo-svn.t +++ /test-subrepo-svn.t.err @@ -273,10 +273,10 @@ 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ cd t/s $ svn status - ? * a (glob) - X * externals (glob) - ? * f1 (glob) - ? * f2 (glob) + ? f1 + ? f2 + ? a + X externals Performing status on external item at 'externals'* (glob)

test-convert-svn-source: fix non-determinism This test was failing randomly with: --- /tests/test-convert-svn-source.t +++ /tests/test-convert-svn-source.t.err @@ -35,8 +35,8 @@ $ svnurl="file://$svnpath/svn-repo/proj%20B" $ svn import -m "init projB" projB "$svnurl" | fixpath + Adding projB/tags Adding projB/mytrunk - Adding projB/tags Committed revision 1.

patch: be more tolerant with EOLs in binary diffs (issue2870) The only place where an trailing CR could be meaningful is in the "diff --git" line as part of a filename, and existing code already rule out this possibility. Extend the CR/LF filtering to the whole binary hunk.

patch: include file name in binary patch error messages $ hg import --no-commit ../mercurial_1915035238540490516.patch applying ../mercurial_1915035238540490516.patch abort: could not extract binary data Becomes: abort: could not extract "binary2" binary data

patch: display a nice error for invalid base85 data Before, import was terminating with a traceback. Now it says: $ hg import --no-commit ../bad.patch applying ../bad.patch abort: could not decode binary patch: bad base85 character at position 66

revset: fix adds/modifies/removes and patterns (issue3403) The fast path was triggered if the argument was not like "type:value", with type a known pattern type. This is wrong for several reasons: - path:value is valid for the fast path - '*' is interpreted as a glob by default and is not valid for fast path Fast path detection is now done after the pattern is parsed, and the normalized path is extracted for direct comparison. All this seems a bit complicated, it is tempting to drop the fast path completely. Also, the hasfile() revset does something similar (only check .files()), without a fast path. If the fast path is really that efficient maybe it should be used there too. Note that: $ log 'modifies("set:modified()")' is different from: $ log 'modifies("*")' because of the usual merge ctx.files()/status(ctx.p1(), ctx) differences. Reported by Steffen Eichenberg <steffen.eichenberg@msg-gillardon.de>

merge with i18n

i18n-pt_BR: synchronized with e3c7ca15cde2

merge with i18n

i18n-pt_BR: synchronized with 83622954b64d

largefiles: notice dirty large files in a subrepo Summary and commit use dirty() to check the status of a subrepository, so this overrides dirty() in the subrepo in the same manner as status() to check the large files instead of their standins. Previously, if only a large file was changed in a subrepo, summary in the top level repo would not report the subrepo was dirty and commit -S would report nothing changed. If any type of file was changed in the top repo and only a large file in the subrepo, commit -S would not commit the changes to the subrepo.

largefiles: fix status -S reporting of subrepos (issue3231) Wrapping the status command will only invoke overridestatus() and set the lfstatus field for the top level repository. Wrapping the status function is required to set the field on child repositories. Previously, status -S would report large files in a subrepo as '?' regardless of their actual states, and was inconsistent with what status would report from within that subrepo.

i18n: use locale insensitive format for datetimes as intermediate representation (issue3398) on some non "en" locale environments, "hg convert" is aborted, because "util.parsedate()" fails. it fails in "memctx.__init__()" called by "putcommit()" of "convert". in "hg convert", datetimes gotten from source repository are usually formatted by "util.datestr()" with default format "%a %b %d %H:%M:%S %Y %1%2". but on some environments, "%a" and "%b" may cause locale sensitive string, and such string may cause parse error in "util.parsedate()". this path uses "%Y-%m-%d %H:%M:%S %1%2" as intermediate representation format for datetimes, because it consists only of locale insensitive elements. datetimes in above format are only used for passing them from conversion logic to memctx object, so it doesn't have to be formatted by locale sensitive one. this patch just avoids locale sensitivity problem of "datestr()" and "parsedate()" combintion.

alias: fix shell alias documentation (issue3374) Described behaviour was the one before shell alias argument handling was reworked by f853873fc66d mid-2010.

test-convert-svn-sink: add helper to smooth svn xml output svnxml.py parses "svn log --xml" output and prints the attributes shared among all tested svn versions. This fixes the test with svn 1.7. Tested with svn 1.6.12 and 1.7.4.

convert/svn: make svn sink work with svn 1.7 "svn add file" now fails if "file" is already tracked. To filter them we have to mirror the svn manifest in the sink. Tested with svn 1.6.12 and 1.7.4.

docs: don't use :hg: at the beginning of lines in notes (issue3397) It seem like docutils 0.8 interpret ':hg:`command`' roles at the beginning of indented lines in '.. note::' directives as a field that is an invalid argument to the directive. It fails with 'Error in "note" directive: invalid option block.' Docutils 0.7 accepted this arguably incorrect markup. Reflowing the text makes the problem go away. A leading '\ ' could perhaps also be used to mask the problem.

rebase: skip resolved but emptied revisions When rebasing, if a conflict occurs and is resolved in a way the rebased revision becomes empty, it is not skipped, unlike revisions being emptied without conflicts. The reason is: - File 'x' is merged and resolved, merge.update() marks it as 'm' in the dirstate. - rebase.concludenode() calls localrepo.commit(), which calls localrepo.status() which calls dirstate.status(). 'x' shows up as 'm' and is unconditionnally added to the modified files list, instead of being checked again. - localrepo.commit() detects 'x' as changed an create a new revision where only the manifest parents and linkrev differ. Marking 'x' as modified without checking it makes sense for regular merges. But in rebase case, the merge looks normal but the second parent is usually discarded. When this happens, 'm' files in dirstate are a bit irrelevant and should be considered 'n' possibly dirty instead. That is what the current patch does. Another approach, maybe more efficient, would be to pass another flag to merge.update() saying the 'branchmerge' is a bit of a lie and recordupdate() should call dirstate.normallookup() instead of merge(). It is also tempting to add this logic to dirstate.setparents(), moving from two to one parent is what invalidates the 'm' markers. But this is a far bigger change to make. v2: succumb to the temptation and move the logic in dirstate.setparents(). mpm suggested trying _filecommit() first but it is called by commitctx() which knows nothing about the dirstate and comes too late into the game. A second approach was to rewrite the 'm' state into 'n' on the fly in dirstate.status() which failed for graft in the following case: $ hg init repo $ cd repo $ echo a > a $ hg ci -qAm0 $ echo a >> a $ hg ci -m1 $ hg up 0 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg mv a b $ echo c > b $ hg ci -m2 created new head $ hg graft 1 --tool internal:local grafting revision 1 $ hg --config extensions.graphlog= glog --template '{rev} {desc|firstline}\n' @ 3 1 | o 2 2 | | o 1 1 |/ o 0 0 $ hg log -r 3 --debug --patch --git --copies changeset: 3:19cd7d1417952af13161b94c32e901769104560c tag: tip phase: draft parent: 2:b5c505595c9e9a12d5dd457919c143e05fc16fb8 parent: -1:0000000000000000000000000000000000000000 manifest: 3:3d27ce8d02241aa59b60804805edf103c5c0cda4 user: test date: Thu Jan 01 00:00:00 1970 +0000 extra: branch=default extra: source=a03df74c41413a75c0a42997fc36c2de97b26658 description: 1 Here, revision 3 is created because there is a copy record for 'b' in the dirstate and thus 'b' is considered modified. But this information is discarded at commit time since 'b' content is unchanged. I do not know if discarding this information is correct or not, but at this time we cannot represent it anyway. This patch therefore implements the last solution of moving the logic into dirstate.setparents(). It does not sound crazy as 'm' files makes no sense with only one parent. It also makes dirstate.merge() calls .lookupnormal() if there is one parent, to preserve the invariant. I am a bit concerned about introducing this kind of stateful behaviour to existing code which historically treated setparents() as a basic setter without side-effects. And doing that during the code freeze.

test-rebase: exhibit revisions which should have been skipped This will be fixed in the next commit. v2: - Display emptied grafted revisions - Use --git flag

transplant: do not rollback on patching error (issue3379) Otherwise, all transplanted revisions are gone and the failing one cannot be fixed (unless it is the first one). I do not know what is the expected behaviour with rollback, probably something pull-like. Non-conflicting cases should work as previously. But something like: $ hg transplant r1 r2 commiting r1 as c1 failing r2 $ hg transplant --continue committing r2 as c2 $ hg rollback would reset the repository to its state before the "transplant --continue" instead of the whole transplant session. To fix this we might need a way to open an existing journal file, not sure this is worth the pain.

patch: fix patch hunk/metdata synchronization (issue3384) Git patches are parsed in two phases: 1) extract metadata, 2) parse actual deltas and merge them with the previous metadata. We do this to avoid dependency issues like "modify a; copy a to b", where "b" must be copied from the unmodified "a". Issue3384 is caused by flaky code I wrote to synchronize the patch metadata with the emitted hunk: if (gitpatches and (gitpatches[-1][0] == afile or gitpatches[-1][1] == bfile)): gp = gitpatches.pop()[2] With a patch like: diff --git a/a b/c copy from a copy to c --- a/a +++ b/c @@ -1,1 +1,2 @@ a +a @@ -2,1 +2,2 @@ a +a diff --git a/a b/a --- a/a +++ b/a @@ -1,1 +1,2 @@ a +b the first hunk of the first block is matched with the metadata for the block "diff --git a/a b/c", then the second hunk of the first block is matched with the metadata of the second block "diff --git a/a b/a", because of the "or" in the code paste above. Turning the "or" into an "and" is not enough as we have to deal with /dev/null cases for each file. We I remove this broken piece of code: # copy/rename + modify should modify target, not source if gp.op in ('COPY', 'DELETE', 'RENAME', 'ADD') or gp.mode: afile = bfile because "afile = bfile" set "afile" to stuff like "b/file" instead of "a/file", and because this only happens for git patches, which afile/bfile are ignored anyway by applydiff(). v2: - Avoid a traceback on git metadata desynchronization

commit: use ui.configbool when checking 'commitsubrepos' setting on --amend Before this fix, having [ui] commitsubrepos = False in the config file lead to $ hg ci --amend -mx abort: cannot amend recursively

doc: add note about pattern rooted/unrooted cases to "hgignore" and "patterns" each help topics describe that patterns are "not rooted" and "rooted" in themselves, but not describe about each other. so, this may causes misunderstanding about "rooted"-ness of patterns.

doc: add description about location of management files for subrepo

doc: add description about re-opening closed heads to 'Head, closed branch' in glossary

doc: fix careless document miss for term 'Close changeset' in glossary there is no term 'Changeset, close' in glossary. 'Close changeset' seems to have to be linked not to 'Branch, closed', but to 'Head, closed branch', because only the latter explains about "the changeset that marks a head as no longer interesting".

doc: fix careless document miss in help of hgext/notify according to configuration example below, and direction of changeset transference, this paragraph should describe about "changegroup" hook. [hooks] # one email for each incoming changeset incoming.notify = python:hgext.notify.hook # one email for all incoming changesets changegroup.notify = python:hgext.notify.hook # one email for all outgoing changesets outgoing.notify = python:hgext.notify.hook

doc: fix explanation comment in acl extension according to configuration in "acl.deny" below, group "@hg-denied" also be denied for all files, so add such description to comment for configuration. [acl.deny] # user6 will not have write access to any file: ** = user6 # Group "hg-denied" will not have write access to any file: ** = @hg-denied

tests: test test-filelog is python - rename to test-filelog.py

tests: avoid tab indent on all kinds of lines of sh commands

tests: use 'do sleep 0' instead of 'do true', also on first line of command f64b25f147d7 established that '... do true ...' shouldn't be used, but that was only enforced on continued lines.

check-code: put grouping around regexps generated from testpats This removes the pitfall that would make the testpath r'a|b' match 'b' on all lines in .t tests.

tests: don't use /dev/urandom for largefiles testing There is no need to use entropy here just to create some content that only will be used for hashing and ignored. This avoids a problem where dd from /dev/urandom on solaris generates too short output.

encoding: protect against non-ascii default encoding If the default python encoding was changed from ascii, the attempt to encode as ascii before lower() could throw a UnicodeEncodeError. Catch UnicodeError instead to prevent an unhandled exception.

update: fix case-collision with a clean wd and no --clean cbf2ea2f5ca1 introduced some logic to avoid case-collision detection between source and destination revisions when it does not make sense: clean or to be cleaned working directories. Unfortunately, part of it was flawed and the related test was broken by another bug. This patch disables cross revision case collision detection for updates without option or with --check, if the working directory is clean.

update: make --check abort with dirty subrepos Aka "we could use dirty() but... yeah let's use it"

update: fix "not rev" vs "rev is None"