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.
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 1f543fd375c5 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.
7ad43b163555 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.
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
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
"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.
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.
