Sat, 01 Feb 2020 10:54:20 +0100 obslog: extract display of a markers to its own function draft
Rodrigo Damazio Bovendorp <rdamazio@google.com> [Sat, 01 Feb 2020 10:54:20 +0100] rev 5250
obslog: extract display of a markers to its own function
Mon, 27 Jan 2020 14:55:35 +0700 tests: allow an empty merge commit to have tests pass without too many changes draft stable
Anton Shestakov <av6@dwimlabs.net> [Mon, 27 Jan 2020 14:55:35 +0700] rev 5249
tests: allow an empty merge commit to have tests pass without too many changes Not the greatest fix, but this allows us to have the same test case for all versions of Mercurial. Hash of 29 changes because instead of both parents only one is set in hg 5.3.
Sun, 26 Jan 2020 20:52:25 +0700 uncommit: use repo.setparents() instead of repo.dirstate.setparents() draft stable
Anton Shestakov <av6@dwimlabs.net> [Sun, 26 Jan 2020 20:52:25 +0700] rev 5248
uncommit: use repo.setparents() instead of repo.dirstate.setparents() setparents() was added to localrepository class in 2012, and now we finally have some differences between calling repo.setparents() vs repo.dirstate.setparents(): _quick_access_* things, introduced in hg 5.3. This patch fixes potential quick-access desync problems where repo[b'.'] would be different from repo.dirstate.p1().
Sun, 26 Jan 2020 20:57:20 +0700 touch: use repo.setparents() instead of repo.dirstate.setparents() draft stable
Anton Shestakov <av6@dwimlabs.net> [Sun, 26 Jan 2020 20:57:20 +0700] rev 5247
touch: use repo.setparents() instead of repo.dirstate.setparents() setparents() was added to localrepository class in 2012, and now we finally have some differences between calling repo.setparents() vs repo.dirstate.setparents(): _quick_access_* things, introduced in hg 5.3. This patch fixes potential quick-access desync problems where repo[b'.'] would be different from repo.dirstate.p1().
Sun, 26 Jan 2020 20:57:39 +0700 evolve: use repo.setparents() instead of repo.dirstate.setparents() draft stable
Anton Shestakov <av6@dwimlabs.net> [Sun, 26 Jan 2020 20:57:39 +0700] rev 5246
evolve: use repo.setparents() instead of repo.dirstate.setparents() setparents() was added to localrepository class in 2012, and now we finally have some differences between calling repo.setparents() vs repo.dirstate.setparents(): _quick_access_* things, introduced in hg 5.3. This patch fixes an actual quick-access desync problem where repo[b'.'] would be different from repo.dirstate.p1(), as demonstrated by test-evolve-phase-divergence.t when ran on hg 5.3rc0 and later. Modified _uncommitdirstate() too, because it is used in dirstatedance(), which sometimes follows repo.setparents() calls.
Mon, 02 Sep 2019 20:09:05 +0700 tests: demonstrate that evolve swaps parents of merge commits draft stable
Anton Shestakov <av6@dwimlabs.net> [Mon, 02 Sep 2019 20:09:05 +0700] rev 5245
tests: demonstrate that evolve swaps parents of merge commits Tests currently pass, don't forget to change FIXME items.
Wed, 22 Jan 2020 21:41:25 +0700 ci: cache pytype-related files between runs draft
Anton Shestakov <av6@dwimlabs.net> [Wed, 22 Jan 2020 21:41:25 +0700] rev 5244
ci: cache pytype-related files between runs
Sun, 10 Nov 2019 16:32:34 +0530 evolve: add pre-check logic for creation of phase divergence locally draft
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 10 Nov 2019 16:32:34 +0530] rev 5243
evolve: add pre-check logic for creation of phase divergence locally Changes in tests reflect the added behaviour.
Sun, 10 Nov 2019 18:08:57 +0530 evolve: add test to show that user can create phase-divergence locally draft
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 10 Nov 2019 18:08:57 +0530] rev 5242
evolve: add test to show that user can create phase-divergence locally After resolution of phase-divergence, user can locally create phase-divergence by rewriting the old bumped (obsolete now) changeset. Next patch will be adding the pre-check logic for creation of this phase-divergence.
Mon, 30 Dec 2019 00:24:09 +0530 evolve: remove unnecessary code since it's been covered already draft
Sushil khanchi <sushilkhanchi97@gmail.com> [Mon, 30 Dec 2019 00:24:09 +0530] rev 5241
evolve: remove unnecessary code since it's been covered already We don't need this logic any more since the case of "two divergent csets where one is the parent of other" has been handled correctly by the logic present in method _prepcontentdivresolution() This is how things works in method _prepcontentdivresolution() for our case i.e "content-divergence with parent-child relation": cset_b (content-divergent) | cset_a (content-divergent) | ~ Acc. to revision selection criteria: "divergent" = min_revision(cset_a, cset_b) So always "divergent" will be cset_a and "other" will be "cset_b" and resolution parent will be the successor of parent of cset_a Both the csets will be merged and resolution cset will be based on correct revision. The result could be wrong only in the case when "divergent" is cset_b which is not possible acc. to the current logic.
Mon, 30 Dec 2019 00:43:17 +0530 test: no need to look at full log draft
Sushil khanchi <sushilkhanchi97@gmail.com> [Mon, 30 Dec 2019 00:43:17 +0530] rev 5240
test: no need to look at full log
Sun, 29 Dec 2019 23:59:41 +0530 evolve: refactor content-divergence resolution logic draft
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 29 Dec 2019 23:59:41 +0530] rev 5239
evolve: refactor content-divergence resolution logic > What is the case we are looking at? This is about refactoring the part of content-div resolution logic where it decides which cset should be relocated and where. > What is a "topologicial common ancestors" vs a "greatest common ancestors"? `tca` is an ancestor which we can decide/find by looking at the at graph visually for e.g ``` c3(*) c4(*) | | c2(x) c1(x) c5 | / \ | / c0 ``` (c5 is the successor of c2 and c1) now here, `tca` of c3 and c4 is: c0 `gca` of c3 and c4 is: c5 > What is the new top-level logic/behavior that makes it better? The old code had some unnecessary edge cases just because we were using `gca`, since it can point to a revision that is not a topological ancestor. For e.g see b779b40f996e Eventually, the code around this was getting messy unnecessarily. So I looked into it and found a simple and more robust approach. And in new code, it is simple and straightforward (and easy to understand), where we handle the following 4 cases when solving content-div: 1) when both are on the same parent => (no need to do anything special, and simply proceed) 2) both are on the different parent but a) `tca` is the parent of one of them or b) there is no non-obsolete revision between `tca` and one of the divergent cset. => (relocate one to the other side and proceed) 3) both are on different parents and `tca` is not the parent of any of them and there is at least one non-obsolete cset between tca and both the divergent cset i.e (tca::div1) and (tca::div2) both the ranges have at least one non-obs revision. => (this is the case which we don't handle yet, but the solution would be to prompt the user to choose an evolve destination.) 4) both are in the parent-child relation => (both are merged and new cset will be based on the successor of `tca`) Changes in test-evolve-issue5958.t demonstrate that new code also covered case4 because in a resolution of "two divergent csets with parent-child relation" there should be one cset as a result and no orphan revs (as you can see there was an orphan before this patch).
(0) -3000 -1000 -300 -100 -12 +12 +100 tip