Thu, 22 Sep 2016 18:11:37 +0900 dagop: change visit dict of filectxancestors() indexed solely by rev
Yuya Nishihara <yuya@tcha.org> [Thu, 22 Sep 2016 18:11:37 +0900] rev 35274
dagop: change visit dict of filectxancestors() indexed solely by rev In future patches, a max heap will be used to compute the next revision to visit.
Thu, 22 Sep 2016 18:01:55 +0900 dagop: use fctx.rev() consistently in filectxancestors()
Yuya Nishihara <yuya@tcha.org> [Thu, 22 Sep 2016 18:01:55 +0900] rev 35273
dagop: use fctx.rev() consistently in filectxancestors() We can't use fctx.linkrev() to sort fctxs coming from multiple files. This was changed at 24b57c3899f8 due to performance issue, but we know we evaluate parent.rev() in revset anyway.
Thu, 22 Sep 2016 17:48:46 +0900 dagop: yield intro filectx by filectxancestors()
Yuya Nishihara <yuya@tcha.org> [Thu, 22 Sep 2016 17:48:46 +0900] rev 35272
dagop: yield intro filectx by filectxancestors() This is the convention of dagop.*ancestors() functions.
Sun, 22 Oct 2017 17:23:34 +0900 filectx: extract helper method to obtain filectx pointing to its introrev
Yuya Nishihara <yuya@tcha.org> [Sun, 22 Oct 2017 17:23:34 +0900] rev 35271
filectx: extract helper method to obtain filectx pointing to its introrev
Thu, 22 Sep 2016 17:16:53 +0900 dagop: copy basefilectx.ancestors() to free function
Yuya Nishihara <yuya@tcha.org> [Thu, 22 Sep 2016 17:16:53 +0900] rev 35270
dagop: copy basefilectx.ancestors() to free function The primary goal of this series is to make follow() support multiple start revisions. dagop.filectxancestors() will be extended to take multiple filectxs. basefilectx.ancestors() is not forwarded to this function because doing that would resurrect the performance issue fixed by 24b57c3899f8.
Thu, 22 Sep 2016 15:52:09 +0900 test-log: test that fctx.ancestors() can't index parents only by linkrev
Yuya Nishihara <yuya@tcha.org> [Thu, 22 Sep 2016 15:52:09 +0900] rev 35269
test-log: test that fctx.ancestors() can't index parents only by linkrev This covers a possible bug that could be caused by the following change: --- a/mercurial/context.py +++ b/mercurial/context.py @@ -1047,7 +1047,7 @@ class basefilectx(object): while True: for parent in c.parents()[:cut]: - visit[(parent.linkrev(), parent.filenode())] = parent + visit[parent.linkrev()] = parent if not visit: break c = visit.pop(max(visit))
Tue, 17 Oct 2017 15:27:22 +0200 pull: retrieve bookmarks through the binary part when possible
Boris Feld <boris.feld@octobus.net> [Tue, 17 Oct 2017 15:27:22 +0200] rev 35268
pull: retrieve bookmarks through the binary part when possible This makes pull consistent with the part used by push and provide us with a more compact representation of bookmarks. In addition, this opens the way for smarter bookmark exchanges (e.g. filtering by names or only sending the bookmark relevant to the pulled set, etc).
Tue, 17 Oct 2017 15:27:17 +0200 getbundle: add support for 'bookmarks' boolean argument
Boris Feld <boris.feld@octobus.net> [Tue, 17 Oct 2017 15:27:17 +0200] rev 35267
getbundle: add support for 'bookmarks' boolean argument This new argument requests a 'bookmarks' part from the server. It is meant to be used instead of the "listkeys" request.
Tue, 17 Oct 2017 15:26:16 +0200 bundle2: support a 'records' mode for the 'bookmarks' part
Boris Feld <boris.feld@octobus.net> [Tue, 17 Oct 2017 15:26:16 +0200] rev 35266
bundle2: support a 'records' mode for the 'bookmarks' part In this mode, the bookmarks changes are record in the 'bundleoperation' records instead of inflicted to the repository. This is necessary to use the part when pulling.
Tue, 17 Oct 2017 15:39:34 +0200 bundle2: add a 'modes' dictionary to the bundle operation
Boris Feld <boris.feld@octobus.net> [Tue, 17 Oct 2017 15:39:34 +0200] rev 35265
bundle2: add a 'modes' dictionary to the bundle operation This new attribute allows the codes requesting an unbundling to pass important information to individual part handlers. The current target use case is to allow for receiving 'bookmarks' part without directly updating local repository, but just recording the received data instead. This is necessary for pull where the remote bookmarks are processed locally. I expect the concept to be beneficial to other parts in the future. To clarify the bookmark behavior on pull, the remote bookmark value are not just taken -as-is- into the local repository. There is an extra step to detect bookmark divergence. The remote bookmarks data are stored until this processing happens.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip