Mercurial > hg
view mercurial/py3kcompat.py @ 21933:8ecbe55fd09d stable
largefiles: invoke "normallookup" on "lfdirstate" for merged files
Before this patch, largefiles gotten from "other" revision (with
conflict) at "hg merge" become "clean" unexpectedly in steps below:
1. "repo.status()" is invoked (for status check before merging)
1-1 "dirstate" entry for standinfile SF is "normal"-ed
1-2 "lfdirstate" entry of largefile LF (for SF) is "normal"-ed
2. "merge.update()" is invoked
2-1 SF is updated in the working directory
(ASSUMPTION: user choice "other" at conflict)
2-2 "dirstate" entry for SF is "merge"-ed
3. "lfcommands.updatelfiles()" is invoked (by "overrides.hgmerge()")
3-1 largefile LF (for SF) is updated in the working directory
3-2 "dirstate" returns "m" for SF (by 2-2)
3-3 "lfdirstate" entry for LF is left as it is
3-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and
timestamp of LF is stored into "lfdirstate" file (by 1-2)
(ASSUMPTION: timestamp of LF differs from one of "lfdirstate" file)
Then, "hs status" treats LF as "clean", even though LF is updated by
"other" revision (by 3-1), because "lfilesrepo.status()" always treats
"normal"-ed files (by 1-2 and 3-4) as "clean".
When state of standinfile in "dirstate" is "m", largefile should be
"normallookup"-ed.
This patch invokes "normallookup" on "lfdirstate" for merged files.
This patch uses "[debug] dirstate.delaywrite" feature in the test, to
ensure that timestamp of the largefile gotten from "other" revision is
stored into ".hg/largefiles/dirstate". (for ASSUMPTION at 3-4)
author | FUJIWARA Katsunori <foozy@lares.dti.ne.jp> |
---|---|
date | Wed, 23 Jul 2014 00:10:24 +0900 |
parents | a7a9d84f5e4a |
children | 5bfd01a3c2a9 |
line wrap: on
line source
# py3kcompat.py - compatibility definitions for running hg in py3k # # Copyright 2010 Renato Cunha <renatoc@gmail.com> # # This software may be used and distributed according to the terms of the # GNU General Public License version 2 or any later version. import builtins from numbers import Number def bytesformatter(format, args): '''Custom implementation of a formatter for bytestrings. This function currently relies on the string formatter to do the formatting and always returns bytes objects. >>> bytesformatter(20, 10) 0 >>> bytesformatter('unicode %s, %s!', ('string', 'foo')) b'unicode string, foo!' >>> bytesformatter(b'test %s', 'me') b'test me' >>> bytesformatter('test %s', 'me') b'test me' >>> bytesformatter(b'test %s', b'me') b'test me' >>> bytesformatter('test %s', b'me') b'test me' >>> bytesformatter('test %d: %s', (1, b'result')) b'test 1: result' ''' # The current implementation just converts from bytes to unicode, do # what's needed and then convert the results back to bytes. # Another alternative is to use the Python C API implementation. if isinstance(format, Number): # If the fixer erroneously passes a number remainder operation to # bytesformatter, we just return the correct operation return format % args if isinstance(format, bytes): format = format.decode('utf-8', 'surrogateescape') if isinstance(args, bytes): args = args.decode('utf-8', 'surrogateescape') if isinstance(args, tuple): newargs = [] for arg in args: if isinstance(arg, bytes): arg = arg.decode('utf-8', 'surrogateescape') newargs.append(arg) args = tuple(newargs) ret = format % args return ret.encode('utf-8', 'surrogateescape') builtins.bytesformatter = bytesformatter origord = builtins.ord def fakeord(char): if isinstance(char, int): return char return origord(char) builtins.ord = fakeord if __name__ == '__main__': import doctest doctest.testmod()