merge with stable

hook: flush stdout before redirecting to stderr When hook output redirection is enabled (e.g. when cloning over ssh), hook output on stdout is redirected to stderr, to prevent the repository data on stdout from being corrupted. In certain cases, the redirection could cause part of the repository data to end up on stderr as well. In case of a clone, this causes: "abort: consistency error in delta!" This was seen with a clone over ssh, an outgoing hook present (any non-python type, e.g. 'pwd'), on certain repositories only, probably depending on the distribution of the sent data) This patch updates the hook redirection code to flush stdout before redirecting, removing the problem.

import: fix parent selection when importing merges With "wp1" and "wp2" the current working directory parents, "p1" and "p2" the patch parents and "parents" the resulting commit parents, the current behaviour is: --bypass --exact p2 parents 0 0 0 [wp1, wp2] 0 0 1 [wp1, wp2]/buggy 0 1 0 [p1] 0 1 1 [p1, p2] 1 0 0 [wp1, wp2] 1 0 1 [p1, p2] 1 1 0 [p1] 1 1 1 [p1, p2] The original behaviour before f53dc0787424 was: --bypass --exact p2 parents 0 0 0 [wp1, wp2] 0 0 1 if p1 == wp1 then [p1, p2] otherwise [wp1, wp2] 0 1 0 [p1] 0 1 1 [p1, p2] This patch restores the previous behaviour when --bypass is not set, and align --bypass behaviour when --exact is not set with merge diffs.

patch: simplify hunk extents parsing Do not capture unwanted groups in regexps

diff: --ignore-blank-lines was too enthusiastic It was ignoring changes from: ab to: a b

graft: disallow grafting grafted csets in specific situations (issue3091) In particular, we do not allow: - grafting an already grafted cset onto its original branch - grafting already grafted csets with the same origin onto each other

graft: use revs to make tests more readable

graft: preserve original source in subsequent grafts

makedate: wrong timezone offset if DST rules changed this year (issue2511) Python's time module sets timezone and altzone based on UTC offsets of two dates: first and middle day of the current year. This approach doesn't work on a year when DST rules change. For example Russia abandoned winter time this year, so the correct UTC offset should be +4 now, but time.timezone returns 3 hours difference because that's what it was on 01.01.2011. Related python issue: http://bugs.python.org/issue1647654

posix: fix findexe() to check for file type and access

forget: use forward slashes for internal paths forget into a subrepo failed on windows because pathes were joined with \.

check-code: add --nolineno option for hiding line numbers This makes the output more stable when it is used as a whitelist.

merge: give a special message for internal:merge failure (issue3105)

setup: raise when executing with python3 without c2to3 argument

posix: fix findexe() to check for file type and access

subrepo: use correct paths for subrepos with ..-relative paths on windows posixpath normpath of c:\foo\bar/../baz is baz, so now we pconvert first.

add missing localization markup

url: handle file://localhost/c:/foo "correctly" The path was parsed correctly, but localpath prepended an extra '/' (as in '/c:/foo') because it assumed it was an absolute unix path.

help: it is 'file://localhost/', not 'file://local/' The documentation has apparently always been wrong.

setup: support executing with python3 including 2to3 Merge the code from contrib/setup3.py in setup. The argument for executing is marked as experimental. Reason: The file in contrib was outdated (packages, cmdclass, ...)

setup: hgbuildmo inherits from Command hgbuildmo does not need anything provided by the build class.

setup: make script executable with python3 Replace the incompatible print statement. Writing a warning to stderr is a good idea anyway.

bookmark: remove excess creation of changectx's

bookmark: same order for options and code

merge with stable

dirstate: fix case-folding identity for traditional Unix We used to use os.path.normcase which was a no-op, which was unhelpful for cases like VFAT on Linux.

convert/bzr: fix test of divergent nested renames for bzr 1.x 54c0517c0fe8 introduced a new block in test-convert-bzr-directories.t which produces a slightly different output with older bzr versions. Tested with bzr 1.5 on Debian lenny.

phases: set common changeset to public on pull

phases: mark content pushed as public in local repo on push

phases: marked content of a changegroup as published

phases: set new commit in 1-phase

phases: add retractboundary function to move boundary backward The advanceboundary documentation is updated to highlight the difference.

phases: rename moveboundary into advance boundary This rename prepare the creation of retract boundaru that move boundary backward

phases: remove underbar into target_phase argument

merge with stable

tests: fix trailing whitespace

merge with stable

mq: add a warning about uncommitted changes for qfinish

hgweb: add hint about finding library path with debuginstall

forget: support forgetting explicit paths in subrepos Change the behavior of the forget command such that explicit paths in subrepos are handled by forgetting the file in the subrepo. This eliminates the previous behavior where if you called "hg forget" for an explicit path in a subrepo, it would state that the file is already untracked.

tests: add test for behavior of forget for explicit path in subrepo Adds a section to test-subrepo.t that demonstrates the current behavior when you pass the full path to a file in a subrepo to hg forget.

largefiles: treat status of cache missed largefiles as "missing" correctly "hg status" may treat cache missed largefiles as "removed" incorrectly. assumptions for problem case: - there is no cache for largefile "L" - at first, update working directory to the revision in which "L" is not yet added, - then, update working directory to the revision in which "L" is already added and now, "hg status" treats "L" as "removed". current implementation does not allocate entry for cache missed largefile in ".hg/largefiles/dirstate", but files without ".hg/largefiles/dirstate" entry are treated as "removed" by largefiles extension. "hg revert" can not recover from this situation, but "rm -rf .hg/largefiles", because it causes dirstate rebuilding. this patch invokes normallookup() for cache missed largefiles to allocate entry in ".hg/largefiles/dirstate", so "hg status" can treat it as "missing" correctly.

merge with stable

merge with i18n

rebase: ensure target is not taken as external (issue3085) This could happen in specific situations in which 'target' was selected as external and used for p1 _and_ p2.

merge with i18n

i18n: merge with stable

i18n-da: add new strings from Mercurial 2.0

i18n-ru: fix translation of --logfile (issue3095)

rebase: treat nullmerge as a special case in rebasestate (issue3046) When storing/restoring a nullmerge (-2), a 'standard' conversion was made and an existing changeset was wrongly used. Nullmerge should instead be treated as a special case.

graft: mark a string for translation

mdiff/patch: fix bad hunk handling for unified diffs with zero context Prior to this patch "hg diff -U0", i.e., zero lines of context, would output hunk headers with a start line one greater than what GNU patch and git output. Guido van Rossum documents the unified diff format[1] as having a start line value "one lower than one would expect" for zero length hunks. Comparing the behaviour of the three systems prior to this patch in transforming c1 c3 to c1 c2 c3 - GNU "diff -U0" reports the hunk as "@@ -1,0 +2 @@" - "git diff -U0" reports the hunk as "@@ -1,0 +2 @@" - "hg diff -U0" reports the hunk as "@@ -2,0 +2,1 @@" After this patch, "hg diff -U0" reports "@@ -1,0 +2,1 @@". Since "hg export --config diff.unified=0" outputs zero-context unified diffs, "hg import" has also been updated to account for start lines one less than expected for zero length hunk ranges. [1]: http://www.artima.com/weblogs/viewpost.jsp?thread=164293

convert/bzr: correctly handle divergent nested renames (issue3089) With renames like: a -> b a/c -> a/c We were ignoring or duplicating the second one instead of leaving files unchanged or moving them to their proper destination only. To avoid this, we process the files in reverse lexicographic order, from most to least specific change, and ignore files already processed. v2: - Add a test - Change "reverse=1" into "reverse=True"

setup: subclass build command

setup: has_ext_modules always returns false when pure is specified When pure is specified ext_modules is emptied in hgbuildpy.finalize_options. Before this happens has_ext_modules returned True.

setup: subclass distribution instead of overwriting original