Before, it was possible to create a
.hg/largefiles/hash
file with truncated content, i.e., content where
SHA-1(content) != hash
This breaks the fundamental invariant in largefiles that the file
content for files in .hg/largefiles hash to the filename.
OS X does the following transformation on paths for comparisons:
a) 8-bit strings are decoded as UTF-8 to UTF-16
b) undecodable bytes are percent-escaped
c) accented characters are converted to NFD decomposed form, approximately
d) characters are converted to _lowercase_ using internal tables
Both (c) and (d) are done using internal tables that vary from release
to release and match Unicode specs to greater or lesser extent. We
approximate these functions using Python's internal Unicode data.
With this change, Mercurial will (in almost all cases) match OS X
folding and not report unknown file aliases for files in UTF-8 or
other encodings.
Operating on a non-existant file can cause both IOError and OSError,
depending on the function used: open raises IOError, os.lstat raises
OSError.
The largefiles code called dirstate.normal, which in turn calls
os.lstat, so OSError is the right exception to catch here.
This help entry didn't try to describe the 'localhost' notation. It described a
non-standard host-less notation where 'local' just was the first part of a
sample relative path. It describe "urls" with relative and absolute paths like:
file://file.txt
file:///tmp/file.txt
file://c:/tmp/file.txt
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.
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
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.
"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.
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.
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
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"
When (1) findfile links a largefile from the user cache to the store
and (2) the store directory doesn't exist yet, findfile errors out. A
simple call to util.makedirs fixes it.
