Mon, 26 Jun 2017 09:33:01 +0900 formatter: proxy fm.context() through converter
Yuya Nishihara <yuya@tcha.org> [Mon, 26 Jun 2017 09:33:01 +0900] rev 33090
formatter: proxy fm.context() through converter Otherwise nested template formatter would not see the context objects. It's just a boolean flag now. We might want to change it to 'ctxs -> items' function so changectx attributes are populated automatically in JSON, but I'm not sure.
Mon, 26 Jun 2017 09:18:55 +0900 identify: change p1/p2 to a list of parents
Yuya Nishihara <yuya@tcha.org> [Mon, 26 Jun 2017 09:18:55 +0900] rev 33089
identify: change p1/p2 to a list of parents It makes sense because the nested data structure is a list of items.
Sun, 25 Jun 2017 13:31:56 -0700 scmutil: add a cleanupnodes method for developers
Jun Wu <quark@fb.com> [Sun, 25 Jun 2017 13:31:56 -0700] rev 33088
scmutil: add a cleanupnodes method for developers It's now common that an old node gets replaced by zero or more new nodes, that could happen with amend, rebase, histedit, etc. And it's a common requirement to do bookmark movements, strip or obsolete nodes and even moving working copy parent. Previously, amend, rebase, history have their own logic doing the above. This patch is an attempt to unify them and future code. This enables new developers to be able to do "replace X with Y" thing correctly, without any knowledge about bookmarks, strip or obsstore. The next step will be migrating rebase to the new API, so it works inside a transaction, and its code could be simplified.
Sun, 25 Jun 2017 10:38:45 -0700 strip: add a delayedstrip method that works in a transaction
Jun Wu <quark@fb.com> [Sun, 25 Jun 2017 10:38:45 -0700] rev 33087
strip: add a delayedstrip method that works in a transaction For long, the fact that strip does not work inside a transaction and some code has to work with both obsstore and fallback to strip lead to duplicated code like: with repo.transaction(): .... if obsstore: obsstore.createmarkers(...) if not obsstore: repair.strip(...) Things get more complex when you want to call something which may call strip under the hood. Like you cannot simply write: with repo.transaction(): .... rebasemod.rebase(...) # may call "strip", so this doesn't work But you do want rebase to run inside a same transaction if possible, so the code may look like: with repo.transaction(): .... if obsstore: rebasemod.rebase(...) obsstore.createmarkers(...) if not obsstore: rebasemod.rebase(...) repair.strip(...) That's ugly and error-prone. Ideally it's possible to just write: with repo.transaction(): rebasemod.rebase(...) saferemovenodes(...) This patch is the first step towards that. It adds a "delayedstrip" method to repair.py which maintains a postclose callback in the transaction object.
Sun, 25 Jun 2017 22:30:14 -0700 workingfilectx: add audit() as a wrapper for wvfs.audit()
Phil Cohen <phillco@fb.com> [Sun, 25 Jun 2017 22:30:14 -0700] rev 33086
workingfilectx: add audit() as a wrapper for wvfs.audit()
Sun, 25 Jun 2017 22:30:14 -0700 workingfilectx: add backgroundclose as a kwarg to write()
Phil Cohen <phillco@fb.com> [Sun, 25 Jun 2017 22:30:14 -0700] rev 33085
workingfilectx: add backgroundclose as a kwarg to write() This is necessary because some callers in merge.py pass backgroundclose=True when writing. As with previous changes in this series, this should be a no-op.
Sun, 25 Jun 2017 22:29:09 -0700 merge: change repo.wvfs.setflags calls to a new wctx[f].setflags function
Phil Cohen <phillco@fb.com> [Sun, 25 Jun 2017 22:29:09 -0700] rev 33084
merge: change repo.wvfs.setflags calls to a new wctx[f].setflags function As with previous changes in this series, this should be a no-op.
Sun, 25 Jun 2017 17:00:15 -0700 merge: convert repo.wwrite() calls to wctx[f].write()
Phil Cohen <phillco@fb.com> [Sun, 25 Jun 2017 17:00:15 -0700] rev 33083
merge: convert repo.wwrite() calls to wctx[f].write() As with the previous patch in this series, workingfilectx.write() is a direct call to repo.wwrite(), so this change should be a no-op.
Sun, 25 Jun 2017 16:58:26 -0700 merge: replace repo.wvfs.unlinkpath() with calls to wctx[f].remove()
Phil Cohen <phillco@fb.com> [Sun, 25 Jun 2017 16:58:26 -0700] rev 33082
merge: replace repo.wvfs.unlinkpath() with calls to wctx[f].remove() The code inside workingfilectx.remove() is a straight call to repo.wvfs.unlinkpath, so this should be a no-op.
Sun, 25 Jun 2017 16:56:49 -0700 merge: pass wctx to batchremove and batchget
Phil Cohen <phillco@fb.com> [Sun, 25 Jun 2017 16:56:49 -0700] rev 33081
merge: pass wctx to batchremove and batchget We would like to migrate direct calls of repo.wvfs/wwrite/wread/etc to a call on the relevant workingfilectx, both as a cleanup (to reduce the number of working copy functions on `repo`), and also to facilitate an in-memory merge that doesn't write to the working copy. In order to do that, the first step is to ensure we pass the target wctx around and perform our writes and reads on it. Later, this object might become a memctx.
Sat, 24 Jun 2017 23:05:57 +0900 revset: add depth limit to descendants() (issue5374)
Yuya Nishihara <yuya@tcha.org> [Sat, 24 Jun 2017 23:05:57 +0900] rev 33080
revset: add depth limit to descendants() (issue5374) This is naive implementation using two-pass scanning. Tracking descendants isn't an easy problem if both start and stop depths are specified. It's impractical to remember all possible depths of each node while scanning from roots to descendants because the number of depths explodes. Instead, we could cache (min, max) depths as a good approximation and track ancestors back when needed, but that's likely to have off-by-one bug. Since this implementation appears not significantly slower, and is quite straightforward, I think it's good enough for practical use cases. The time and space complexity is O(n) ish. revisions: 0) 1-pass scanning with (min, max)-depth cache (worst-case quadratic) 1) 2-pass scanning (this version) repository: mozilla-central # descendants(0) (for reference) *) 0.430353 # descendants(0, depth=1000) 0) 0.264889 1) 0.398289 # descendants(limit(tip:0, 1, offset=10000), depth=1000) 0) 0.025478 1) 0.029099 # descendants(0, depth=2000, startdepth=1000) 0) painfully slow (due to quadratic backtracking of ancestors) 1) 1.531138
Sat, 24 Jun 2017 23:35:03 +0900 dagop: make walk direction switchable so it can track descendants
Yuya Nishihara <yuya@tcha.org> [Sat, 24 Jun 2017 23:35:03 +0900] rev 33079
dagop: make walk direction switchable so it can track descendants # ancestors(tip) using hg repo 2) 0.068527 3) 0.069097
Sat, 24 Jun 2017 23:30:51 +0900 dagop: factor out generator of ancestor nodes
Yuya Nishihara <yuya@tcha.org> [Sat, 24 Jun 2017 23:30:51 +0900] rev 33078
dagop: factor out generator of ancestor nodes # ancestors(tip) using hg repo 1) 0.068976 2) 0.068527
Sat, 24 Jun 2017 23:22:45 +0900 dagop: factor out pfunc from revancestors() generator
Yuya Nishihara <yuya@tcha.org> [Sat, 24 Jun 2017 23:22:45 +0900] rev 33077
dagop: factor out pfunc from revancestors() generator This generator will be reused for tracking descendants with depth limit. # ancestors(tip) using hg repo 0) 0.065868 1) 0.068976
Fri, 23 Jun 2017 21:15:10 +0900 dagop: use smartset.min() in revdescendants() generator
Yuya Nishihara <yuya@tcha.org> [Fri, 23 Jun 2017 21:15:10 +0900] rev 33076
dagop: use smartset.min() in revdescendants() generator All callers pass the result of revset.getset(), which should be a smartset.
Tue, 20 Jun 2017 22:26:52 +0900 dagop: change revdescendants() to include all root revisions
Yuya Nishihara <yuya@tcha.org> [Tue, 20 Jun 2017 22:26:52 +0900] rev 33075
dagop: change revdescendants() to include all root revisions Prepares for adding depth support. I want to process depth=0 in revdescendants() to make things simpler. only() also calls dagop.revdescendants(), but it filters out root revisions explicitly. So this should cause no problem. # descendants(0) using hg repo 0) 0.052380 1) 0.051226 # only(tip) using hg repo 0) 0.001433 1) 0.001425
(0) -30000 -10000 -3000 -1000 -300 -100 -16 +16 +100 +300 +1000 +3000 +10000 tip