"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.
$DAEMON_PIDS is used by tests to make sure there will be no leftover
processes, the cycling through ports is needed because they are not
available for a new bind that quickly on some systems.
There are not enough $HGPORT variables available for each hg serve,
so use the killdaemons script before reusing ports.
While Chrome, Firefox, and IE 6+ support the current date format being
passed to Date(), Safari doesn't:
> new Date('Mon Oct 24 13:58:01 2011 +0200')
Invalid Date
However, the rfc822date format--officially supported by
ECMAScript[1]--does work:
> new Date('Mon, 24 Oct 2011 13:58:01 +0200')
Mon Oct 24 2011 04:58:01 GMT-0700 (PDT)
This change replaces all instances of {date|date} in HTML with
{date|rfc822date}. For elements that only have the "age" class,
there's no outward change for users with JavaScript enabled. For
elements with both the "age" and "date" classes, the full date
displayed uses the new format.
Tested in IE 6, Safari 5.1.1, Google Chrome 15, and Firefox 7.0.1.
[1]: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date/parse
When dirstate parent is changed with dirstate.setparent before a
revert so it no longer points to where the dirstate refered to, revert
does not remove all files it should:
Revert to a different revision needs also to remove files that are not
found through disptables and not in the context or parent manifest.
- old-style patterns without ^ were getting improperly anchored
- finditer was matching against beginning of line poorly
- \s was matching newlines
- [^x] was matching newlines
so we:
- remove earlier hacks for multiline matching
- fix unified test anchoring by adding .*
- replace \s with [ \t]
- replace [^x] with [^\nx]
- force all matches into multiline mode so ^ anchors work
This uncovers a number of test issues that are then repaired.
The code was using the size of a symlink's target, thus wrongly making symlinks
to large files into largefiles themselves. This can be demonstrated by
deleting the symlink and then doing an 'hg up' or 'hg up -C' to restore the
symlink.
This reveals a small bug: revert reports "reverting .hglf/largefile"
when it really should report "reverting largefile". I don't see an
easy fix, though (short of using ui.pushbuffer() to interfere with
revert's output).
The 'Bin' marker was added to every changed file for which we could not find
any diff changes. This included binary files but also copy/renames and mode
changes. Since Mercurial regular diff format emits a 'Binary file XXX has
changed' line when fed with binary files, we use that and the usual git marker
to tell them from other cases. In particular, new empty files are no longer
reported as binary.
Still, this fix is not complete since copy/renames/mode changes are now
reported as '0' lines changes, instead of 'Bin'.
