Mon, 21 Jan 2019 23:06:10 +0530 evolve: update the public divergence resolution logic to cover --continue case
Sushil khanchi <sushilkhanchi97@gmail.com> [Mon, 21 Jan 2019 23:06:10 +0530] rev 4384
evolve: update the public divergence resolution logic to cover --continue case To continue the interrupted evolve in case of public divergence: we will have to store the node of that public cset which was in content divergence with the other cset, so that we can perform the phase divergence resolution between that public cset and a newnode which is the result of content-divergence resolution. Added tests reflect the behaviour this patch adds.
Mon, 21 Jan 2019 23:06:34 +0530 evolve: add logic to resolve content-divergence with a public cset
Sushil khanchi <sushilkhanchi97@gmail.com> [Mon, 21 Jan 2019 23:06:34 +0530] rev 4383
evolve: add logic to resolve content-divergence with a public cset Public content-divergence is the divergence where a cset is content-divergent with a public cset. To solve public divergence: 1) perform content-divergent resolution 2) resultant node is phase divergent 3) perform phase divergence resolution It is the intial logic to solve public divergence. Next patches will be the covering the cases of: 1) relocation: when we need to relocate to node 2) continue: to add this resolution in case of --continue 3) the case when content-divergence resolution gives a result similar to public cset. Added test-evolve-public-content-divergent.t reflect the added behaviour.
Sun, 13 Jan 2019 19:33:19 +0530 evolve: introduce function to create a obsmarker relation even for public cset
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 13 Jan 2019 19:33:19 +0530] rev 4382
evolve: introduce function to create a obsmarker relation even for public cset To create obsmarkers we use obsolete.createmarkers() function, but because of security reasons this function refuses to create obsmarkers for public cset. And we need to create obsmarkers for a public cset while solving public content divergence. So introducing this function which create a obsmarker relation even for immutable cset. Currently this function create obsmarker for a single relation, in contrast of obsolete.createmarkers() which create markers for multiple relations. Upcoming pathces will be using this function.
Tue, 29 Jan 2019 20:45:14 +0800 topic: make ranges work in revset relations like 'foo#stack[1:2]'
Anton Shestakov <av6@dwimlabs.net> [Tue, 29 Jan 2019 20:45:14 +0800] rev 4381
topic: make ranges work in revset relations like 'foo#stack[1:2]'
Mon, 28 Jan 2019 22:31:31 +0800 topic: simplify #stack index check/access
Anton Shestakov <av6@dwimlabs.net> [Mon, 28 Jan 2019 22:31:31 +0800] rev 4380
topic: simplify #stack index check/access Also using stack.revs instead of list(stack). It's equivalent and stack.revs is @propertycache'd.
Sun, 27 Jan 2019 17:39:09 +0800 topic: make ranges work in revset relations like 'foo#topic[1:2]'
Anton Shestakov <av6@dwimlabs.net> [Sun, 27 Jan 2019 17:39:09 +0800] rev 4379
topic: make ranges work in revset relations like 'foo#topic[1:2]' Since #topic is very similar to #generations, we reuse the function directly. Few tests because #generations is already tested in core.
Fri, 25 Jan 2019 16:51:36 +0530 evolve: add description of function solveobswdp
Sushil khanchi <sushilkhanchi97@gmail.com> [Fri, 25 Jan 2019 16:51:36 +0530] rev 4378
evolve: add description of function solveobswdp
Wed, 23 Jan 2019 12:11:36 -0800 evolve: document the "if not shouldupdate" block
Martin von Zweigbergk <martinvonz@google.com> [Wed, 23 Jan 2019 12:11:36 -0800] rev 4377
evolve: document the "if not shouldupdate" block I missed the "not" in "if not shouldupdate: ... hg.updaterepo()" and it took a long time for me to realize it's about updating *back* to the original commit (or to its successor). Let's add a comment to maybe help the person not make the same mistake.
(0) -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 tip