Change the behavior of the add command such that explicit paths in
subrepos are always added. This eliminates the previous behavior
where if you called "hg add" for an explicit path in a subrepo
without specifying the -S option, it would be silently ignored.
If you specify patterns, or no arguments at all, the -S option
will still be needed to activate recursion into subrepos.
Add test coverage for the existing behavior where adds of explicit paths in
subrepos are silently ignored. This is in preparation for changing the
behavior of the add command to have better support for subrepos.
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'.
