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
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.
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().
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().
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.
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.
Anton Shestakov <av6@dwimlabs.net> [Wed, 22 Jan 2020 21:41:25 +0700] rev 5244
ci: cache pytype-related files between runs
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.
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.
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.
Sushil khanchi <sushilkhanchi97@gmail.com> [Mon, 30 Dec 2019 00:43:17 +0530] rev 5240
test: no need to look at full log
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).