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.
Complex merges with divergent renames can cause a file to be 'moved'
twice, causing dirstate.drop() to be called twice. Rather than try to
ensure there are no unexpected corner cases where this can happen, we
simply ignore drops of files that aren't tracked.
This fix mirrors the changes made to test-doctest.py in 04cfbbc5ae97
and 39599b7929c4.
Without this change, tests running heredoctest.py can fail on certain
versions of OS X when TERM is set to xterm-256color:
$ /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python -m heredoctest <<EOF
> >>> open('b', 'w').write('this' * 1000)
> EOF
+ \x1b[?1034h (no-eol) (esc)
A similar problem occurs with test-url.py:
$ ./run-tests.py test-url.py
--- .../tests/test-url.py.out
+++ .../tests/test-url.py.err
@@ -0,0 +1 @@
+
ERROR: .../test-url.py output changed
!
Failed test-url.py: output changed
# Ran 1 tests, 0 skipped, 1 failed.
# this change redones part of e0051068893a, backed out by 38c00c035629
Some character encodings use ASCII characters other than
control/alphabet/digit as a part of multi-bytes characters, so direct
replacing with such characters on strings in local encoding causes
invalid byte sequences.
[mpm: test changed to simple doctest]
When largefiles is enabled, commands on large repositories which don't
require largefiles could be slowed down substantially. Disable
checking this for every command.
