Fri, 03 Aug 2018 12:47:15 -0700 changegroup: make some packer attributes private
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 03 Aug 2018 12:47:15 -0700] rev 38903
changegroup: make some packer attributes private These methods and attributes are low level and should not be called or outside outside of instances. Indicate as such through naming. Differential Revision: https://phab.mercurial-scm.org/D4085
Fri, 03 Aug 2018 10:35:10 -0700 changegroup: rename cg1packer to cgpacker
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 03 Aug 2018 10:35:10 -0700] rev 38902
changegroup: rename cg1packer to cgpacker There is now only a single class. We don't need to encode the version in its name since the version is a lie. Differential Revision: https://phab.mercurial-scm.org/D4084
Fri, 03 Aug 2018 10:35:02 -0700 changegroup: control delta parent behavior via constructor
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 03 Aug 2018 10:35:02 -0700] rev 38901
changegroup: control delta parent behavior via constructor The last remaining override on cg2packer related to parent delta computation. We pass a parameter to the constructor to control whether to delta against the previous revision and we inline all parent delta logic into a single function. With this change, cg2packer is empty, so it has been deleted. Differential Revision: https://phab.mercurial-scm.org/D4083
Fri, 03 Aug 2018 10:01:58 -0700 changegroup: control reordering via constructor argument
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 03 Aug 2018 10:01:58 -0700] rev 38900
changegroup: control reordering via constructor argument cg2packer.__init__ exists just to override self._reorder. Let's parameterize this behavior via an argument to the parent's __init__. The logic for self._reorder is kinda wonky. None is used as a special value and the value should be None in some situations. It is probably worth rewriting this logic to make behavior more explicit. This will likely happen as part of future work to control the delta generation process that I have planned. Differential Revision: https://phab.mercurial-scm.org/D4082
Fri, 03 Aug 2018 09:44:30 -0700 changegroup: consolidate tree manifests sending into cg1packer
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 03 Aug 2018 09:44:30 -0700] rev 38899
changegroup: consolidate tree manifests sending into cg1packer Previously, we overrode a method to control how manifests were serialized. This method was redefined on cg3packer to send tree manifests. This commit moves the tree manifests sending variation to cg1packer and teaches the cgpacker constructor to control which version to use. After these changes, cg3packer was empty. So it has been removed. Differential Revision: https://phab.mercurial-scm.org/D4081
Thu, 02 Aug 2018 18:04:51 -0700 changegroup: pass end of manifests marker into constructor
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 02 Aug 2018 18:04:51 -0700] rev 38898
changegroup: pass end of manifests marker into constructor cg3 inserts a custom marker in the stream once all manifests have been transferred. This is currently abstracted out by overriding a method. Let's pass the end of manifests marker in as an argument to avoid the extra method. Differential Revision: https://phab.mercurial-scm.org/D4080
Thu, 02 Aug 2018 17:44:56 -0700 changegroup: pass function to build delta header into constructor
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 02 Aug 2018 17:44:56 -0700] rev 38897
changegroup: pass function to build delta header into constructor Previously, the delta header struct format was defined on each class and each class had a separate function for building the delta header. We replace both of these with an argument to __init__ containing a callable that can format a delta header given a revisiondelta instance. Differential Revision: https://phab.mercurial-scm.org/D4079
Thu, 02 Aug 2018 17:52:21 -0700 changegroup: make delta header struct formatters actual structs
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 02 Aug 2018 17:52:21 -0700] rev 38896
changegroup: make delta header struct formatters actual structs Why we weren't using compiled Struct instances, I don't know. They make code simpler. In theory they are faster. Although I don't believe I was able to measure any meaningful change. That could be because this code is often dominated by compression, deltafication, and function call overhead. Differential Revision: https://phab.mercurial-scm.org/D4078
Thu, 02 Aug 2018 17:33:23 -0700 changegroup: pass version into constructor
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 02 Aug 2018 17:33:23 -0700] rev 38895
changegroup: pass version into constructor Currently, the version is an attribute on each class. Passing the argument into the constructor gets us one step closer to eliminating cg2packer and cg3packer. Differential Revision: https://phab.mercurial-scm.org/D4077
Thu, 02 Aug 2018 17:29:53 -0700 changegroup: define functions for creating changegroup packers
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 02 Aug 2018 17:29:53 -0700] rev 38894
changegroup: define functions for creating changegroup packers Currently, we have 3 classes for changegroup generation. Each class handles a specific changegroup format. And each subsequent version's class inherits from the previous one. The interface for the classes is not very well defined and a lot of version-specific behavior is behind overloaded functions. This approach adds complexity and makes changegroup generation difficult to reason about. Upcoming commits will be consolidating these 3 classes so differences between changegroup versions and changegroup generation are controlled by parameters to a single constructor / type rather than by overriding class attributes via inheritance. We begin this process by building dedicated functions for creating each changegroup packer instance. Currently they just call the constructor on the appropriate class. This will soon change. Differential Revision: https://phab.mercurial-scm.org/D4076
Fri, 03 Aug 2018 10:05:26 -0700 changegroup: capture revision delta in a data structure
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 03 Aug 2018 10:05:26 -0700] rev 38893
changegroup: capture revision delta in a data structure The current changegroup generation code is tightly coupled to the revlog API. This tight coupling makes it difficult to implement alternate storage backends without requiring a large surface area of the revlog API to be exposed. This is not desirable. In order to support changegroup generation with non-revlog storage, we'll need to abstract the concept of delta generation. This commit is the first step down that road. We introduce a data structure for representing a delta in a changegroup. The API still leaves a lot to be desired. But at least we now have separation between data and actions performed on it. As part of this, we tweak behavior slightly: we no longer concatenate the delta prefix with the metadata header. Instead, we track and emit the prefix as a separate chunk. This shouldn't have any meaningful impact since all the chunks just get sent to the wire, the compressor, etc. Because we're introducing a new object, this does add some overhead to changegroup execution. `hg perfchangegroupchangelog` on my clone of the Mercurial repo (~40,000 visible revisions in the changelog) slows down a bit: ! wall 1.268600 comb 1.270000 user 1.270000 sys 0.000000 (best of 8) ! wall 1.419479 comb 1.410000 user 1.410000 sys 0.000000 (best of 8) With for `hg bundle -t none-v2 -a /dev/null`: before: real 6.610 secs (user 6.460+0.000 sys 0.140+0.000) after: real 7.210 secs (user 7.060+0.000 sys 0.140+0.000) I plan to claw back this regression in future commits. And I may even do away with this data structure once the refactor is complete. For now, it makes things easier to comprehend. Differential Revision: https://phab.mercurial-scm.org/D4075
Thu, 02 Aug 2018 16:36:40 -0700 changegroup: inline ellipsisdata()
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 02 Aug 2018 16:36:40 -0700] rev 38892
changegroup: inline ellipsisdata() There's only one caller of it. I don't think it needs to exist as a standalone function. Differential Revision: https://phab.mercurial-scm.org/D4074
Thu, 02 Aug 2018 17:05:11 -0700 changegroup: rename "revlog" variables
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 02 Aug 2018 17:05:11 -0700] rev 38891
changegroup: rename "revlog" variables "revlog" shadows the module import. But more importantly, changegroup generation should be storage agnostic and not assume the existence of revlogs. Let's rename the thing providing revision storage to "store" to reflect this ideal property. Differential Revision: https://phab.mercurial-scm.org/D4073
Thu, 02 Aug 2018 14:15:10 -0700 changegroup: move generate() modifications from narrow
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 02 Aug 2018 14:15:10 -0700] rev 38890
changegroup: move generate() modifications from narrow Narrow had a custom version of generate() that was essentially a copy of generate() with inline additions to facilitate ellipses serving. This commit inlines those modifications into generate(). Differential Revision: https://phab.mercurial-scm.org/D4067
Thu, 02 Aug 2018 12:18:35 -0700 changegroup: move generatefiles() from narrow
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 02 Aug 2018 12:18:35 -0700] rev 38889
changegroup: move generatefiles() from narrow The code is a bit ugly in that it overrides the linknodes function that is passed in as a function. I'd like to think that the caller of generatefiles() would pass in the appropriate function. We can clean this up later. Differential Revision: https://phab.mercurial-scm.org/D4066
Thu, 02 Aug 2018 12:12:12 -0700 changegroup: move _sortgroup() from narrow
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 02 Aug 2018 12:12:12 -0700] rev 38888
changegroup: move _sortgroup() from narrow Differential Revision: https://phab.mercurial-scm.org/D4065
Thu, 02 Aug 2018 09:52:01 -0700 changegroup: move close() from narrow
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 02 Aug 2018 09:52:01 -0700] rev 38887
changegroup: move close() from narrow More of the same. Differential Revision: https://phab.mercurial-scm.org/D4064
Thu, 02 Aug 2018 09:53:22 -0700 changegroup: move revchunk() from narrow
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 02 Aug 2018 09:53:22 -0700] rev 38886
changegroup: move revchunk() from narrow The monkeypatched revchunk for ellipses serving is a completely independent implementation. We model it as such in the changegroup code. revchunk() is now a simple proxy function. Again, I wish we had better APIs here. Especially since this narrow code is part of cg1packer and cg1packer can't be used with narrow. Class inheritance is wonky. And I will definitely be making changes to changegroup code for delta generation. As part of the code move, `node.nullrev` was replaced by `nullrev`. And a reference to `orig` was replaced to call `self._revchunknormal` directly. Differential Revision: https://phab.mercurial-scm.org/D4063
Thu, 02 Aug 2018 09:40:18 -0700 changegroup: move deltaparent() from narrow
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 02 Aug 2018 09:40:18 -0700] rev 38885
changegroup: move deltaparent() from narrow I'm not keen on performing the attribute sniff to test for presence of ellipses mode: I'd rather we use a separate packer instance that was ellipses mode specific. But I've tried to formalize a better API without narrow in core and I can't make sense of all the monkeypatching. My goal is to inline as much of the monkeypatching as possible then refactor the changegroup generation API. We add this code to the cg2packer because narrow doesn't work with cg1. Differential Revision: https://phab.mercurial-scm.org/D4062
Sat, 28 Jul 2018 17:59:37 -0700 changegroup: move _packellipsischangegroup() from narrow
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 28 Jul 2018 17:59:37 -0700] rev 38884
changegroup: move _packellipsischangegroup() from narrow The behavior here is not ideal, as the function constructs a packer then adds attributes to it. This will be cleaned up in subsequent commits. Moving this code is necessary to move the remainder of the bundle2-level changegroup part generation code into core. Differential Revision: https://phab.mercurial-scm.org/D4061
Sat, 28 Jul 2018 17:52:21 -0700 changegroup: move ellipsisdata() from narrow
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 28 Jul 2018 17:52:21 -0700] rev 38883
changegroup: move ellipsisdata() from narrow This is a pretty straightforward copy of the function. Differential Revision: https://phab.mercurial-scm.org/D4060
Sun, 22 Jul 2018 19:48:50 +0900 fileset: narrow status computation by left-hand-side of 'and' node
Yuya Nishihara <yuya@tcha.org> [Sun, 22 Jul 2018 19:48:50 +0900] rev 38882
fileset: narrow status computation by left-hand-side of 'and' node Timing with warm disk cache: $ hg status --cwd mozilla-central 'set:path:build/ and unknown()' --time (orig) time: real 1.970 secs (user 1.560+0.000 sys 0.410+0.000) (new) time: real 0.330 secs (user 0.310+0.000 sys 0.020+0.000)
Sun, 22 Jul 2018 19:43:57 +0900 fileset: move copy constructor of matchctx near __init__
Yuya Nishihara <yuya@tcha.org> [Sun, 22 Jul 2018 19:43:57 +0900] rev 38881
fileset: move copy constructor of matchctx near __init__
Sun, 22 Jul 2018 11:20:48 +0900 fileset: build status according to 'withstatus' hint
Yuya Nishihara <yuya@tcha.org> [Sun, 22 Jul 2018 11:20:48 +0900] rev 38880
fileset: build status according to 'withstatus' hint _switchcallers is no longer needed since 'withstatus' node is reinserted for arguments of functions like revs(). New matchctx instance is created per 'withstatus' to make sure that status tuple is available only for children of the 'withstatus' node.
Sat, 21 Jul 2018 20:27:53 +0900 fileset: insert hints where status should be computed
Yuya Nishihara <yuya@tcha.org> [Sat, 21 Jul 2018 20:27:53 +0900] rev 38879
fileset: insert hints where status should be computed This will allow us to compute status against a narrowed set of files. For example, "path:build/ & (unknown() + missing())" is rewritten as "path:build/ & <withstatus>(unknown() + missing(), 'unknown missing')", and the status call can be narrowed by the left-hand-side matcher, "path:build/". mctx.buildstatus() calls will be solely processed by getmatchwithstatus().
Sun, 22 Jul 2018 11:12:55 +0900 fileset: move buildstatus() to matchctx method
Yuya Nishihara <yuya@tcha.org> [Sun, 22 Jul 2018 11:12:55 +0900] rev 38878
fileset: move buildstatus() to matchctx method In future patches, file status will be computed while evaluating a parsed tree. This patch provides a matchctx interface to build status.
Sun, 22 Jul 2018 10:58:32 +0900 fileset: keep basectx by matchctx
Yuya Nishihara <yuya@tcha.org> [Sun, 22 Jul 2018 10:58:32 +0900] rev 38877
fileset: keep basectx by matchctx
Sun, 22 Jul 2018 10:55:38 +0900 fileset: pass in basectx to _buildstatus()
Yuya Nishihara <yuya@tcha.org> [Sun, 22 Jul 2018 10:55:38 +0900] rev 38876
fileset: pass in basectx to _buildstatus() I'll make matchctx remember both ctx and basectx so that file status between them can be computed later. This prepares for the change.
Sat, 04 Aug 2018 12:58:08 +0530 resolve: update commands.resolve.confirm help text
Sushil khanchi <sushilkhanchi97@gmail.com> [Sat, 04 Aug 2018 12:58:08 +0530] rev 38875
resolve: update commands.resolve.confirm help text Included --mark and --unmark in the help text of resolve.confirm.config. Differential Revision: https://phab.mercurial-scm.org/D4103
Sat, 04 Aug 2018 12:43:41 +0530 resolve: support confirm config option with --unmark flag
Sushil khanchi <sushilkhanchi97@gmail.com> [Sat, 04 Aug 2018 12:43:41 +0530] rev 38874
resolve: support confirm config option with --unmark flag Now, commands.resolve.confirm also respect --unmark option; and confirm to unresolve all resolved files. It will confirm only when no files pats are passed (same as --mark), because when no pats are passed the default is to mark resolved files as unresolved. And if user has passed file pats then I think there is no need to confirm for that. Differential Revision: https://phab.mercurial-scm.org/D4102
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip