- Nov 13, 2011
-
-
Dmitry Panov authored
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
-
- Nov 16, 2011
-
-
Marc-Antoine Ruel authored
-
- Nov 15, 2011
-
-
kiilerix authored
posixpath normpath of c:\foo\bar/../baz is baz, so now we pconvert first.
-
- Nov 11, 2011
-
-
kiilerix authored
-
- Nov 15, 2011
-
-
file://localhost/c:/fookiilerix authored
The path was parsed correctly, but localpath prepended an extra '/' (as in '/c:/foo') because it assumed it was an absolute unix path.
-
file://localhost/file://local/kiilerix authored
The documentation has apparently always been wrong.
-
Matt Mackall authored
We used to use os.path.normcase which was a no-op, which was unhelpful for cases like VFAT on Linux.
-
Thomas Arendsen Hein authored
54c0517c0fe8 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.
-
- Nov 10, 2011
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Katsunori FUJIWARA authored
"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.
-
Matt Mackall authored
-
- Nov 08, 2011
-
-
Stefano Tortarolo authored
This could happen in specific situations in which 'target' was selected as external and used for p1 _and_ p2.
-
- Nov 09, 2011
-
-
Martin Geisler authored
-
Martin Geisler authored
-
- Nov 06, 2011
-
-
Stefano Tortarolo authored
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.
-
- Nov 08, 2011
-
-
Stefano Tortarolo authored
-
- Nov 10, 2011
-
-
Nicolas Venegas authored
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
-
- Nov 08, 2011
-
-
Patrick Mezard authored
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"
-
- Nov 04, 2011
-
-
Martin Geisler authored
-
David M. Carr authored
Add details on which commands are supported for Subversion subrepos.
-
David M. Carr authored
Add details on which commands are supported for git subrepos.
-
David M. Carr authored
Update the subrepo help to be consistent with the new default behavior, which is to abort if any subrepo is dirty.
-
- Nov 03, 2011
-
-
Wagner Bruna authored
This is just a stopgap until a proper solution is implemented.
-
Hao Lian authored
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.
-
Matt Mackall authored
Spotted by Victor Stinner <victor.stinner@haypocalc.com>
-
- Nov 01, 2011
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
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.
-
Brodie Rao authored
This fix mirrors the changes made to test-doctest.py in b856071435f7 and 967adcf5910d. 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.
-
Matt Mackall authored
-
- Oct 31, 2011
-
-
Wagner Bruna authored
-
Wagner Bruna authored
-
Katsunori FUJIWARA authored
-
Katsunori FUJIWARA authored
# this change redones part of 521c8e0c93bf, backed out by 0ad0ebe67815 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]
-
Matt Mackall authored
-
- Oct 20, 2011
-
-
Hao Lian authored
This is consistent with the rest of Mercurial's code, mirroring the try-finally-unlink structure elsewhere. Furthermore, it fixes the case where largefiles throws an IOError on Windows when the temporary file is opened a second time by copytocacheabsolute. This patch creates the temporary file in the repo's largefiles store rather than /tmp, which might be a different filesystem.
-
- Oct 31, 2011
-
-
Matt Mackall authored
Normally this works because we replace util.sha1 with hashlib.sha1 after first use, but if the first user doesn't provide an arg, it breaks.
-
Matt Mackall authored
-
- Oct 30, 2011
-
-
Yuya Nishihara authored
The issue was partially fixed by b357a972d6cd, but there were missing variables to run build_hgextindex.
-