Fri, 03 Oct 2014 21:44:10 -0700 dirstate: separate 'lookup' status field from others
Martin von Zweigbergk <martinvonz@gmail.com> [Fri, 03 Oct 2014 21:44:10 -0700] rev 22911
dirstate: separate 'lookup' status field from others The status tuple returned from dirstate.status() has an additional field compared to the other status tuples: lookup/unsure. This field is just an optimization and not something most callers care about (they want the resolved value of 'modified' or 'clean'). To prepare for a single future status type, let's separate out the 'lookup' field from the rest by having dirstate.status() return a pair: (lookup, status).
Mon, 13 Oct 2014 14:18:47 -0700 commit: update file nodeid and flags in the same place
Martin von Zweigbergk <martinvonz@gmail.com> [Mon, 13 Oct 2014 14:18:47 -0700] rev 22910
commit: update file nodeid and flags in the same place Now that we have a separate variable for the original 'm1' manifest, we can safely update the nodeid of the file in the new manifest in the same place as we update the flags.
Mon, 13 Oct 2014 14:11:47 -0700 commit: use separate variable for p1 manifest and new manifest
Martin von Zweigbergk <martinvonz@gmail.com> [Mon, 13 Oct 2014 14:11:47 -0700] rev 22909
commit: use separate variable for p1 manifest and new manifest In localrepo.commitctx(), p1's manifest is copied and used as the basis for the manifest that is about to be committed. The way the copy is updated makes it safe to use it where the original p1's manifest is wanted. For readability, though, a separate variable for each purpose would be clearer. Make it so.
Mon, 13 Oct 2014 14:34:53 -0700 commit: remove dead initialization of 'lock'
Martin von Zweigbergk <martinvonz@gmail.com> [Mon, 13 Oct 2014 14:34:53 -0700] rev 22908
commit: remove dead initialization of 'lock' The 'lock' variable is initialized to None, but before it's ever read, it's assigned again.
Mon, 13 Oct 2014 16:43:37 -0700 commit: reduce scope of 'removed' variable
Martin von Zweigbergk <martinvonz@gmail.com> [Mon, 13 Oct 2014 16:43:37 -0700] rev 22907
commit: reduce scope of 'removed' variable The variable is closely related to 'added' and 'changed', so it makes sense to have it declared next to them.
Mon, 13 Oct 2014 18:00:39 -0500 rebase: fix some weird mixed-case naming
Matt Mackall <mpm@selenic.com> [Mon, 13 Oct 2014 18:00:39 -0500] rev 22906
rebase: fix some weird mixed-case naming
Mon, 13 Oct 2014 17:55:45 -0500 rebase: move duplicatecopies next to merge
Matt Mackall <mpm@selenic.com> [Mon, 13 Oct 2014 17:55:45 -0500] rev 22905
rebase: move duplicatecopies next to merge This is preparation for removing open-coded rebase/graft operations. As a side-effect, this exposes proper renames in the working copy when there are conflicts, which shows up in test-shelve.t.
Mon, 13 Oct 2014 17:12:47 -0500 histedit: use merge.graft
Matt Mackall <mpm@selenic.com> [Mon, 13 Oct 2014 17:12:47 -0500] rev 22904
histedit: use merge.graft
Mon, 13 Oct 2014 17:12:31 -0500 graft: use merge.graft
Matt Mackall <mpm@selenic.com> [Mon, 13 Oct 2014 17:12:31 -0500] rev 22903
graft: use merge.graft
Mon, 13 Oct 2014 17:12:12 -0500 merge: add merge.graft helper
Matt Mackall <mpm@selenic.com> [Mon, 13 Oct 2014 17:12:12 -0500] rev 22902
merge: add merge.graft helper This will help unify all the open-coded graft/rebase operations.
Mon, 13 Oct 2014 14:33:13 -0500 duplicatecopies: move from cmdutil to copies
Matt Mackall <mpm@selenic.com> [Mon, 13 Oct 2014 14:33:13 -0500] rev 22901
duplicatecopies: move from cmdutil to copies This is in preparation for moving its primary caller into merge.py, which would be a layering violation in the current location.
Mon, 13 Oct 2014 14:04:11 -0500 histedit: fix indent
Matt Mackall <mpm@selenic.com> [Mon, 13 Oct 2014 14:04:11 -0500] rev 22900
histedit: fix indent The duplicatecopies call should be part of the rebase block.
Mon, 13 Oct 2014 13:21:03 -0500 graft: move rebase cleanup code next to actual rebase
Matt Mackall <mpm@selenic.com> [Mon, 13 Oct 2014 13:21:03 -0500] rev 22899
graft: move rebase cleanup code next to actual rebase This is prep for refactoring the rebase logic.
Fri, 10 Oct 2014 13:44:40 -0500 shelve: add a bundlerepo method
Matt Mackall <mpm@selenic.com> [Fri, 10 Oct 2014 13:44:40 -0500] rev 22898
shelve: add a bundlerepo method
Sat, 11 Oct 2014 14:05:09 -0500 dirstate: merge falls through to otherparent
Matt Mackall <mpm@selenic.com> [Sat, 11 Oct 2014 14:05:09 -0500] rev 22897
dirstate: merge falls through to otherparent This lets us more correctly fix the state when we use setparents, as demonstrated in the change in test-graft.t.
Fri, 10 Oct 2014 13:31:06 -0500 dirstate: use 'm' state in otherparent to reduce ambiguity
Matt Mackall <mpm@selenic.com> [Fri, 10 Oct 2014 13:31:06 -0500] rev 22896
dirstate: use 'm' state in otherparent to reduce ambiguity In rebase-like operations where we abandon the second parent, we can correctly fix up the state in setparents.
Fri, 10 Oct 2014 13:05:50 -0500 dirstate: properly clean-up some more merge state on setparents
Matt Mackall <mpm@selenic.com> [Fri, 10 Oct 2014 13:05:50 -0500] rev 22895
dirstate: properly clean-up some more merge state on setparents
Tue, 07 Oct 2014 11:42:37 -0700 phases: move root phase assignment to it's own function
Durham Goode <durham@fb.com> [Tue, 07 Oct 2014 11:42:37 -0700] rev 22894
phases: move root phase assignment to it's own function This moves the initial root phase assignment to it's own function. Future patches which make phase calculations lazy will use this function to pre-fill certain phases which can be deduced from the roots.
Tue, 07 Oct 2014 11:37:54 -0700 phases: add invalidate function
Durham Goode <durham@fb.com> [Tue, 07 Oct 2014 11:37:54 -0700] rev 22893
phases: add invalidate function Phase cache invalidation was spread all over the place. Let's add a function to unify it. Later more will be added to this function.
Sun, 12 Oct 2014 23:30:04 -0700 phases: change phase command change detection
Durham Goode <durham@fb.com> [Sun, 12 Oct 2014 23:30:04 -0700] rev 22892
phases: change phase command change detection A future patch is going to make phase computation lazy, so the phase command can no longer read and diff the entire phase list directly. This changes the phase command to build it's own list for diff purposes.
Fri, 10 Oct 2014 13:09:22 -0700 spanset: remove `.set()` definition
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 13:09:22 -0700] rev 22891
spanset: remove `.set()` definition All my friends are dead.
Fri, 10 Oct 2014 13:08:49 -0700 generatorset: remove `.set()` definition
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 13:08:49 -0700] rev 22890
generatorset: remove `.set()` definition All my friends are dead.
Fri, 10 Oct 2014 13:08:28 -0700 addset: remove `.set()` definition
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 13:08:28 -0700] rev 22889
addset: remove `.set()` definition All my friends are dead.
Fri, 10 Oct 2014 13:08:10 -0700 filteredset: remove `.set()` definition
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 13:08:10 -0700] rev 22888
filteredset: remove `.set()` definition All my friends are dead.
Fri, 10 Oct 2014 13:07:35 -0700 baseset: remove `set()` definition
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 13:07:35 -0700] rev 22887
baseset: remove `set()` definition All my friends are dead.
Fri, 10 Oct 2014 11:27:57 -0700 abstractsmartset: remove `set()` method definition
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 11:27:57 -0700] rev 22886
abstractsmartset: remove `set()` method definition Now that all usages have been removed, we can drop this not so useful part of the API. We can note that the name was wrong all along...
Fri, 10 Oct 2014 14:27:05 -0700 match: check if an object is a baseset using `isascending` instead of `set`
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 14:27:05 -0700] rev 22885
match: check if an object is a baseset using `isascending` instead of `set` The `set()` method is going away.
Fri, 10 Oct 2014 14:22:23 -0700 getset: check if an object is a baseset using `isascending` instead of `set`
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 14:22:23 -0700] rev 22884
getset: check if an object is a baseset using `isascending` instead of `set` The `set()` method is going away.
Fri, 10 Oct 2014 13:24:57 -0700 fullreposet: detect smartset using "isascending" instead of "set"
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 13:24:57 -0700] rev 22883
fullreposet: detect smartset using "isascending" instead of "set" The `.set()` function is going away.
Fri, 10 Oct 2014 13:21:05 -0700 fullreposet: drop custom sets but not smartsets detection
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 13:21:05 -0700] rev 22882
fullreposet: drop custom sets but not smartsets detection All custom classes use by revsets are smartsets now. We drop the special-casing.
Fri, 10 Oct 2014 12:30:00 -0700 addset: drop `.set()` usage during iteration
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 12:30:00 -0700] rev 22881
addset: drop `.set()` usage during iteration We can use the containment check directly.
Fri, 10 Oct 2014 12:31:22 -0700 baseset: access `_set` directly for containment check
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 12:31:22 -0700] rev 22880
baseset: access `_set` directly for containment check The `.set()` method is going away.
Fri, 10 Oct 2014 12:30:56 -0700 baseset: make `_set` a property cache
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 12:30:56 -0700] rev 22879
baseset: make `_set` a property cache This will remove the need for `baseset.set()`.
Fri, 10 Oct 2014 11:27:04 -0700 graphnode: remove usage of `set()`
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 11:27:04 -0700] rev 22878
graphnode: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.
Wed, 08 Oct 2014 02:52:10 -0700 revset-_hexlist: remove usage of `set()`
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 08 Oct 2014 02:52:10 -0700] rev 22877
revset-_hexlist: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.
Wed, 08 Oct 2014 02:51:54 -0700 revset-_intlist: remove usage of `set()`
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 08 Oct 2014 02:51:54 -0700] rev 22876
revset-_intlist: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.
Wed, 08 Oct 2014 02:51:16 -0700 revset-_list: remove usage of `set()`
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 08 Oct 2014 02:51:16 -0700] rev 22875
revset-_list: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.
Wed, 08 Oct 2014 02:50:20 -0700 revset-roots: remove usage of `set()`
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 08 Oct 2014 02:50:20 -0700] rev 22874
revset-roots: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.
Fri, 10 Oct 2014 13:31:00 -0700 histedit: stabilise the order nodes that are stripped
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 10 Oct 2014 13:31:00 -0700] rev 22873
histedit: stabilise the order nodes that are stripped The `nodes` object is a set. We sort it to get stable order. This is going to prevent revsets from getting confused when removing a `.set()` call in `roots`.
Wed, 08 Oct 2014 02:49:17 -0700 revset-origin: remove usage of `set()`
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 08 Oct 2014 02:49:17 -0700] rev 22872
revset-origin: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.
Wed, 08 Oct 2014 02:48:56 -0700 revset-last: remove usage of `set()`
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 08 Oct 2014 02:48:56 -0700] rev 22871
revset-last: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.
Wed, 08 Oct 2014 02:48:24 -0700 revset-limit: remove usage of `set()`
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 08 Oct 2014 02:48:24 -0700] rev 22870
revset-limit: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.
Wed, 08 Oct 2014 02:47:46 -0700 revset-destination: remove usage of `set()`
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 08 Oct 2014 02:47:46 -0700] rev 22869
revset-destination: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.
Wed, 08 Oct 2014 02:47:24 -0700 revset-children: remove usage of `set()`
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 08 Oct 2014 02:47:24 -0700] rev 22868
revset-children: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.
Wed, 08 Oct 2014 02:47:00 -0700 revset-branch: remove usage of `set()`
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 08 Oct 2014 02:47:00 -0700] rev 22867
revset-branch: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.
Wed, 08 Oct 2014 02:45:53 -0700 revset-rangeset: remove usage of `set()`
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 08 Oct 2014 02:45:53 -0700] rev 22866
revset-rangeset: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.
Wed, 08 Oct 2014 02:45:43 -0700 revset-only: remove usage of `set()`
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 08 Oct 2014 02:45:43 -0700] rev 22865
revset-only: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.
Thu, 09 Oct 2014 22:57:52 -0700 revset: cache most conditions used in `filter`
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 09 Oct 2014 22:57:52 -0700] rev 22864
revset: cache most conditions used in `filter` Except when stated otherwise, the condition used in `smartset.filter` will be cached. A new argument has been introduced to disable that behavior. We use it for filters created from `and` and `sub` operations. This gives massive performance boosts for revsets with expensive conditions. revset: branch(stable) or branch(default) before) wall 4.329070 comb 4.320000 user 4.310000 sys 0.010000 (best of 3) after) wall 2.356451 comb 2.360000 user 2.330000 sys 0.030000 (best of 4) revset: author(mpm) or author(lmoscovicz) before) wall 4.434719 comb 4.440000 user 4.440000 sys 0.000000 (best of 3) after) wall 2.321720 comb 2.320000 user 2.320000 sys 0.000000 (best of 4)
Thu, 09 Oct 2014 04:12:20 -0700 baseset: empty or one-element sets are ascending and descending
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 09 Oct 2014 04:12:20 -0700] rev 22863
baseset: empty or one-element sets are ascending and descending The empty set is full of interesting properties. In the ordering case, the one element set is too.
Tue, 07 Oct 2014 01:33:05 -0700 filteredset: drop explicit order management
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 07 Oct 2014 01:33:05 -0700] rev 22862
filteredset: drop explicit order management Now that all low-level smartset classes have proper ordering and fast iteration management, we can just rely on the subset in filteredset.
Thu, 09 Oct 2014 04:24:51 -0700 revset: restore order of `or` operation as in Mercurial 2.9
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 09 Oct 2014 04:24:51 -0700] rev 22861
revset: restore order of `or` operation as in Mercurial 2.9 Lazy revset broke the ordering of the `or` revset. We now stop assuming that two ascending revset are combine into an ascending one. Behavior in 3.0: 3:4 or 2:5 == [2, 3, 4, 5] Behavior in 2.9: 3:4 or 2:5 == [3, 4, 2, 5] We are adding a test for it. For unclear reason, the performance `or` revset with expensive filter are getting even worse than they used to be. This is probably caused by extra uncached containment check or iteration. revset #9: author(lmoscovicz) or author(mpm) before) wall 3.487583 comb 3.490000 user 3.490000 sys 0.000000 (best of 3) after) wall 4.481486 comb 4.480000 user 4.470000 sys 0.010000 (best of 3) revset #10: author(mpm) or author(lmoscovicz) before) wall 3.164839 comb 3.170000 user 3.160000 sys 0.010000 (best of 3) after) wall 4.574965 comb 4.570000 user 4.570000 sys 0.000000 (best of 3)
Thu, 09 Oct 2014 09:12:54 -0700 revset-_descendant: rework the whole sorting and combining logic
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 09 Oct 2014 09:12:54 -0700] rev 22860
revset-_descendant: rework the whole sorting and combining logic We use the & operator to combine with subset (since this is more likely to be optimised than filter) and we enforce the sorting of the result. Without this enforced sorting, we may result in a different iteration order than the set _descendent was computed from. This reverts a bad `test-glog.t` change from 69402eb72115. Another side effect is that `test-mq.t` shows `qparent::` including `-1` if `qparent is -1`. This sound like a positive change. This has good and bad impacts on the benchmarks, here is a good ones: revset: 0:: before) wall 0.045489 comb 0.040000 user 0.040000 sys 0.000000 (best of 100) after) wall 0.034330 comb 0.030000 user 0.030000 sys 0.000000 (best of 100) revset: roots((0::) - (0::tip)) before) wall 0.134090 comb 0.140000 user 0.140000 sys 0.000000 (best of 63) after) wall 0.128346 comb 0.130000 user 0.130000 sys 0.000000 (best of 69) revset: ::p1(p1(tip)):: before) wall 0.143892 comb 0.140000 user 0.140000 sys 0.000000 (best of 55) after) wall 0.124502 comb 0.130000 user 0.130000 sys 0.000000 (best of 65) revset: roots((0:tip)::) before) wall 0.204966 comb 0.200000 user 0.200000 sys 0.000000 (best of 43) after) wall 0.184455 comb 0.180000 user 0.180000 sys 0.000000 (best of 47) Here is a bad one: revset: (20000::) - (20000) before) wall 0.009592 comb 0.010000 user 0.010000 sys 0.000000 (best of 222) after) wall 0.029837 comb 0.030000 user 0.030000 sys 0.000000 (best of 100)
Thu, 09 Oct 2014 20:15:41 -0700 addset: do lazy sorting
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 09 Oct 2014 20:15:41 -0700] rev 22859
addset: do lazy sorting The previous implementation was consuming the whole revset when asked for any sort. The addset class is now doing lazy sorting like all other smarset classes. This has no significant impact in the benchmark as-is. But this is important to later change.
Thu, 09 Oct 2014 04:40:04 -0700 test-import.t: use proper revset order
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 09 Oct 2014 04:40:04 -0700] rev 22858
test-import.t: use proper revset order This test, written after 3.0, is relying on addset being enforced ascending if both side are ascending. We are about to restore the ordering to 2.9 behavior (elements are ordered in the order they are specified). We fix the test before fixing the order.
Thu, 09 Oct 2014 04:29:18 -0700 baseset: drop custom __sub__ method
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 09 Oct 2014 04:29:18 -0700] rev 22857
baseset: drop custom __sub__ method This add method is enforcing non-laziness, disabling multiple optimisations. Benchmarks do not spot any significant difference but real usecase may. This will also be important for further improvements to addset later in this series.
Thu, 09 Oct 2014 04:27:25 -0700 baseset: drop custom __and__ method
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 09 Oct 2014 04:27:25 -0700] rev 22856
baseset: drop custom __and__ method This add method is enforcing non-laziness, disabling multiple optimisations. Benchmarks do not spot any significant regression but real usecase may. This even gives some speedup in some cases: revset #15: min(0::) before) wall 0.001247 comb 0.000000 user 0.000000 sys 0.000000 (best of 1814) after) wall 0.000942 comb 0.000000 user 0.000000 sys 0.000000 (best of 2367) This will also be important for further improvement to addset later in this series.
Thu, 09 Oct 2014 04:27:01 -0700 baseset: drop custom __add__ method
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 09 Oct 2014 04:27:01 -0700] rev 22855
baseset: drop custom __add__ method This add method is enforcing non-laziness, disabling multiple optimisations. Benchmarks do not spot any significant differences but real usecase may. This will also be important for further improvements to addset later in this series.
Tue, 16 Sep 2014 17:57:44 -0700 obsolete: use format version 1 as the default for obsstore
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 16 Sep 2014 17:57:44 -0700] rev 22854
obsolete: use format version 1 as the default for obsstore
Tue, 16 Sep 2014 19:13:08 -0700 test-obsolete: remove subminute timezone in test
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 16 Sep 2014 19:13:08 -0700] rev 22853
test-obsolete: remove subminute timezone in test Obsmarker format "1" does not supports sub minute timezone. So we change the test to something slightly more sensible.
Tue, 16 Sep 2014 17:52:40 -0700 obsolete: add a "format.obsstore-version" config option
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 16 Sep 2014 17:52:40 -0700] rev 22852
obsolete: add a "format.obsstore-version" config option This option controls what version of the binary format to use when creating a new obsstore file. Default is still the old format. No safeguards are currently placed around the option value, but no clueless users are in danger of harm since it is undocumented.
(0) -10000 -3000 -1000 -300 -100 -60 +60 +100 +300 +1000 +3000 +10000 tip