Mon, 13 Mar 2017 10:40:19 +0100 hgweb: handle "parity" internally in webutil.diffs()
Denis Laxalde <denis.laxalde@logilab.fr> [Mon, 13 Mar 2017 10:40:19 +0100] rev 31660
hgweb: handle "parity" internally in webutil.diffs() There's apparently no reason to have the "parity" of diff blocks that webutil.diffs() generates coming from outside the function. So have it internally managed. We thus now pass a "web" object to webutil.diffs() to get access to both "repo" and "stripecount" attribute.
Mon, 27 Mar 2017 09:44:36 +0900 largefiles: add lfile argument to updatestandin() for efficiency (API)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 27 Mar 2017 09:44:36 +0900] rev 31659
largefiles: add lfile argument to updatestandin() for efficiency (API) Before this patch, updatestandin() takes "standin" argument, and applies splitstandin() on it to pick out a path to largefile (aka "lfile" or so) from standin. But in fact, all callers already knows "lfile". In addition to it, many callers knows both "standin" and "lfile". Therefore, making updatestandin() take only one of "standin" or "lfile" is inefficient.
Mon, 27 Mar 2017 09:44:36 +0900 largefiles: use strip() instead of slicing to get rid of EOL of standin
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 27 Mar 2017 09:44:36 +0900] rev 31658
largefiles: use strip() instead of slicing to get rid of EOL of standin This slicing prevents from replacing SHA-1 by another (= longer hash value) in the future.
Mon, 27 Mar 2017 09:44:36 +0900 largefiles: rename local variable appropriately
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 27 Mar 2017 09:44:36 +0900] rev 31657
largefiles: rename local variable appropriately repo['.'] is called not as "working context" but as "parent context". In this code path, hash value of current content of file should be compared against hash value recorded in "parent context". Therefore, "wctx" may cause misunderstanding in this case.
Mon, 27 Mar 2017 09:44:35 +0900 largefiles: avoid redundant loop to eliminate None from list
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 27 Mar 2017 09:44:35 +0900] rev 31656
largefiles: avoid redundant loop to eliminate None from list Before this patch, this code path contains two loops for m._files: one for replacement with standin, and another for elimination of None, which comes from previous replacement ("standin in wctx or lfdirstate[f] == 'r'" case in tostandin()). These two loops can be unified into simple one "for" loop.
Mon, 27 Mar 2017 09:44:35 +0900 largefiles: avoid meaningless changectx looking up
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 27 Mar 2017 09:44:35 +0900] rev 31655
largefiles: avoid meaningless changectx looking up Logically, "repo[ctx.node()]" should be equal to "ctx". In addition to it, this redundant code path is repeated "len(match.m_files)" times.
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.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip