Mon, 27 Mar 2017 09:44:35 +0900 largefiles: avoid redundant changectx looking up at each repetitions
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 27 Mar 2017 09:44:35 +0900] rev 31654
largefiles: avoid redundant changectx looking up at each repetitions These code paths look up changectx at each repetitions, even though the changectx key isn't changed while loop.
Mon, 27 Mar 2017 09:44:34 +0900 largefiles: omit updating newly added standin at linear merging
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 27 Mar 2017 09:44:34 +0900] rev 31653
largefiles: omit updating newly added standin at linear merging Updating standin for newly added largefile is needed, only if same name largefile exists in destination context at linear merging. In such case, updated standin is used to detect divergence of largefile at overridefilemerge(). Otherwise, standin doesn't have any responsibility for its content (usually, it is empty).
Mon, 27 Mar 2017 09:44:34 +0900 largefiles: reuse hexsha1() to centralize hash calculation logic into it
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 27 Mar 2017 09:44:34 +0900] rev 31652
largefiles: reuse hexsha1() to centralize hash calculation logic into it This patch also renames argument of hexsha1(), not only for readability ("data" isn't good name for file-like object), but also for reviewability (including hexsha1() code helps reviewers to confirm how these functions are similar). BTW, copyandhash() has also similar logic, but it can't reuse hexsha1(), because it writes read-in data into specified fileobj simultaneously.
Sun, 26 Mar 2017 19:11:41 +0900 py3: prove second commit works
Yuya Nishihara <yuya@tcha.org> [Sun, 26 Mar 2017 19:11:41 +0900] rev 31651
py3: prove second commit works Finally it works.
Sun, 26 Mar 2017 19:06:48 +0900 py3: fix manifestdict.fastdelta() to be compatible with memoryview
Yuya Nishihara <yuya@tcha.org> [Sun, 26 Mar 2017 19:06:48 +0900] rev 31650
py3: fix manifestdict.fastdelta() to be compatible with memoryview This doesn't look nice, but a straightforward way to support Python 3. bytes(m[start:end]) is needed because a memoryview doesn't support ordering operations. On Python 2, m[start:end] returns a bytes object even if m is a buffer, so calling bytes() should involve no additional copy. I'm tired of trying cleaner alternatives, including: a. extend memoryview to be compatible with buffer type => memoryview is not an acceptable base type b. wrap memoryview by buffer-like class => zlib complains it isn't bytes-like
Sun, 26 Mar 2017 17:00:23 -0700 crecord: use ProgrammingError
Jun Wu <quark@fb.com> [Sun, 26 Mar 2017 17:00:23 -0700] rev 31649
crecord: use ProgrammingError
Sun, 26 Mar 2017 16:59:30 -0700 transaction: use ProgrammingError
Jun Wu <quark@fb.com> [Sun, 26 Mar 2017 16:59:30 -0700] rev 31648
transaction: use ProgrammingError
Sun, 26 Mar 2017 16:57:25 -0700 bundle2: use ProgrammingError
Jun Wu <quark@fb.com> [Sun, 26 Mar 2017 16:57:25 -0700] rev 31647
bundle2: use ProgrammingError
Sun, 26 Mar 2017 16:55:56 -0700 merge: use ProgrammingError
Jun Wu <quark@fb.com> [Sun, 26 Mar 2017 16:55:56 -0700] rev 31646
merge: use ProgrammingError
Sun, 26 Mar 2017 16:53:28 -0700 repair: use ProgrammingError
Jun Wu <quark@fb.com> [Sun, 26 Mar 2017 16:53:28 -0700] rev 31645
repair: use ProgrammingError
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip