- Oct 27, 2011
-
-
Matt Mackall authored
-
Brodie Rao authored
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
-
Matt Mackall authored
-
- Oct 26, 2011
-
-
Peer Stritzinger authored
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.
-
- Oct 27, 2011
-
-
Matt Mackall authored
- 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.
-
- Oct 25, 2011
-
-
Hao Lian authored
-
- Oct 26, 2011
-
-
Eli Carter authored
-
Eli Carter authored
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.
-
Stefano Tortarolo authored
-
Matt Mackall authored
-
- Oct 25, 2011
-
-
Greg Ward authored
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).
-
Greg Ward authored
It works fine; I'm just getting the test coverage up.
-
- Oct 26, 2011
-
-
Matt Mackall authored
-
- Oct 24, 2011
-
-
Patrick Mezard authored
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'.
-
Wagner Bruna authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Thomas Arendsen Hein authored
-
Thomas Arendsen Hein authored
exceptions: hg: os.path.realpath used before util can be imported tests/run-tests.py: may not import mercurial modules
-
Thomas Arendsen Hein authored
This makes test-keyword.t pass on Python 2.4.1 (e.g. Debian sarge)
-
Thomas Arendsen Hein authored
os.path.realpath didn't resolve symlinks that were the first component of the path, see http://bugs.python.org/issue1213894
-
Martin Geisler authored
-
Martin Geisler authored
The extension help text already covered what was in usage.txt and design.txt is now moved to the wiki: http://mercurial.selenic.com/wiki/LargefilesExtension
-
- Oct 23, 2011
-
-
Greg Ward authored
-
Greg Ward authored
-
Matt Mackall authored
On Windows, we store symlinks as plain files with the link contents. Via user error or NFS/Samba assistance, these files often end up with 'normal' file contents. Committing these changes thus gives an invalid symlink that can't be checked out on Unix. Here we filter out any modified symlink placeholders that look suspicious when computing status: - more than 1K (looks more like a normal file) - contain NULs (not allowed on Unix, probably a binary) - contains \n (filenames can't contain \n, very unusual for symlinks, very common for files)
-
Thomas Arendsen Hein authored
-
Thomas Arendsen Hein authored
-
- Oct 22, 2011
-
-
Thomas Arendsen Hein authored
-
Thomas Arendsen Hein authored
If no_proxy (or NO_PROXY) includes localhost, the test for detecting an unreachable proxy fails, because the proxy setting is ignored.
-
Greg Ward authored
This gets us very close to full test coverage of lfconvert. The only features not tested are: - .hgtags conversion - abort when largefile becomes symlink
-
Greg Ward authored
-
Greg Ward authored
- instead of converting a single changeset with a single file, convert two changesets which each add a mix of normal and large files - make one of the large files not-so-large, but identified as large by filename - use shorter, simpler filenames - put some files in a subdirectory - test that file contents are correctly converted - drop unnecessary cleanup step
-
Greg Ward authored
Mainly this is so we can test that code; it has the side benefit of not requiring network I/O to reject non-local repo URLs.
-
Greg Ward authored
-
Greg Ward authored
test-largefiles.t is getting pretty big, and there's lots more to test in lfconvert. And lfconvert is a fairly orthogonal feature to the rest of largefiles.
-
Matt Mackall authored
Before this patch, Windows always did the wrong thing with exec bits when committing a merge: consult the flags in first parent. Now we manually recompute the result of merging flags at commit time, which almost always does the right thing (except when there are conflicts between symlink and exec flags). To do this, we: - pull flag synthesis out into its own function - delay building this function unless it's needed - add a merge case that compares flags in local and other against the ancestor This has been tested in multiple ways on Linux: - running the whole test suite with both old and new code in place, checking for differences in each flags() result - running the whole test suite while comparing real on-disk flags against synthetic ones for merges - test-issue1802 (from Martin Geisler) which disables exec bit checking on Unix
-