Sun, 30 Jun 2019 23:50:57 +0530 compat: fix `setupevolveunfinished` for upstream
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 30 Jun 2019 23:50:57 +0530] rev 4696
compat: fix `setupevolveunfinished` for upstream
Sun, 16 Jun 2019 23:39:55 +0530 evolve: fix the code flow pattern of solving obswdir par and troubled revs
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 16 Jun 2019 23:39:55 +0530] rev 4695
evolve: fix the code flow pattern of solving obswdir par and troubled revs Now we will go to _handlenotrouble() (which prints messages about no revs to solve) only when there is no troubled revs and working dir parent is not obsolete. This change also saves us from an issue which was about looking into the revset (smartset contains troubled revs to solve) when a rev from the revset gets hidden. This happens in the case when our wdir parent is obsolete. After resolving obswdir parent we were looking into the revset to check if there is any troubled revs to solve but we should have performed this check before performing the obswdir resolution. Changes in test file reflect this fixed behaviour.
Sun, 09 Jun 2019 12:07:08 +0530 evolve: refactor for consistent behavior of evolve when wdp is obsolete
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 09 Jun 2019 12:07:08 +0530] rev 4694
evolve: refactor for consistent behavior of evolve when wdp is obsolete This patch make sure that when working directory parent is obsolete `hg evolve` and `hg evolve --all` don't behave differently.
Sat, 15 Jun 2019 17:17:19 +0530 evolve: backout 3027005c42c3 to reintroduce a bug for right fix
Sushil khanchi <sushilkhanchi97@gmail.com> [Sat, 15 Jun 2019 17:17:19 +0530] rev 4693
evolve: backout 3027005c42c3 to reintroduce a bug for right fix This patch backout 3027005c42c3 as it was accepted by mistake while it was being "in-discussion" state.
Fri, 14 Jun 2019 18:17:03 +0800 pick: register pickstate as an unfinished state stable
Anton Shestakov <av6@dwimlabs.net> [Fri, 14 Jun 2019 18:17:03 +0800] rev 4692
pick: register pickstate as an unfinished state This way pickstate file will indicate that unfinished pick command needs to be dealt with (--continue or --abort) before modifying the repo. Otherwise it would be e.g. possible to commit during an interrupted pick and that's not expected.
Fri, 14 Jun 2019 18:14:57 +0800 pick: rename variable for unfinishedstates stable
Anton Shestakov <av6@dwimlabs.net> [Fri, 14 Jun 2019 18:14:57 +0800] rev 4691
pick: rename variable for unfinishedstates
Fri, 14 Jun 2019 18:26:24 +0800 pick: actually delete pickstate if --abort is given stable
Anton Shestakov <av6@dwimlabs.net> [Fri, 14 Jun 2019 18:26:24 +0800] rev 4690
pick: actually delete pickstate if --abort is given Makes pick to be, uh, actually aborted.
Tue, 18 Jun 2019 17:17:31 +0800 evolve: orphans that evolve into nothing don't need successors (issue5967) stable
Anton Shestakov <av6@dwimlabs.net> [Tue, 18 Jun 2019 17:17:31 +0800] rev 4689
evolve: orphans that evolve into nothing don't need successors (issue5967) When continuing to solve an orphan that created no changes (i.e. clean wdir), _completeorphan() used to create an obsmarker that said that the result of that orphan evolution is the currently checked out changeset. That's not a correct obsmarker, because all of the orphan's changes were dropped and so it had no effect on the currently checked out changeset. This is an issue that has only existed when --continu'ing evolve, that's why the fix touches _completeorphan(), but not _solveunstable(). This fix is adapted from a similar "if node is None" block in _finalizerelocate().
Sat, 22 Dec 2018 18:31:32 +0800 tests: demonstrate obsmarker creation after discarding conflicting changes stable
Anton Shestakov <av6@dwimlabs.net> [Sat, 22 Dec 2018 18:31:32 +0800] rev 4688
tests: demonstrate obsmarker creation after discarding conflicting changes Continued evolve creates an incorrect obsmarker that says 2 is a successor of 1. It's incorrect because 1 was dropped as it created no changes to commit (after conflict resolution that discarded its changes). If evolve does the same thing in one go (e.g. just by using --tool :local and without subsequent need to continue) the obsmarker is correct.
Fri, 07 Jun 2019 18:14:48 +0800 pick: remove transaction on the whole command (issue6037) stable
Anton Shestakov <av6@dwimlabs.net> [Fri, 07 Jun 2019 18:14:48 +0800] rev 4687
pick: remove transaction on the whole command (issue6037) At its core, pick is a pretty straightforward and well-behaving command, it uses functions already in core hg, it checks that wdir is clean and that changeset to pick is not public, it checks if there happen to be merge conflicts and can be --continue'd later, etc. It is very similar to graft in core (it also uses mergemod.graft function), but it obsoletes the original changeset. However, graft does not experience this incorrect behavior from issue 6037. What happens in the test case for this issue when we pick a revision that touches both "a" and "b": mergemod.graft() takes the original changeset and tries to apply it to the wdir, which results in "b" being marked as newly added and ready to be committed, "a" updated with the new content and being marked as modified, but "a" also has conflicts. Pick correctly notices this and saves its state before asking for user intervention. So far so good. However, when the command raises InterventionRequired to print a user-facing message and exit while being wrapped in repo.transaction() context manager, the latter partially undoes what mergemod.graft() did: it unmarks "b" as added. And when user continues pick, "b" is therefore not tracked and is not included in the resulting commit. The transaction is not useful here, because it doesn't touch wdir (it's still dirty), it doesn't remove pickstate (and other commands will refuse to work until pick --abort or --continue), it just makes "b" untracked. The solution is to use repo.transaction() only to wrap code that writes data to hg store in the final stages of the command after all checks have passed and is not expected to fail on trivial cases like merge conflicts. For example, committing the picked changeset. But since pick uses repo.commit() for that, and because that function already uses a transaction, wrapping it in another transaction doesn't make sense.
Sun, 23 Dec 2018 01:02:36 +0800 tests: demonstrate hg pick forgetting files after conflicts stable
Anton Shestakov <av6@dwimlabs.net> [Sun, 23 Dec 2018 01:02:36 +0800] rev 4686
tests: demonstrate hg pick forgetting files after conflicts This test currently passes to show that pick is behaving incorrectly.
Thu, 13 Jun 2019 13:27:26 +0800 packaging: follow hg's supported python version (>= 2.7) stable
Anton Shestakov <av6@dwimlabs.net> [Thu, 13 Jun 2019 13:27:26 +0800] rev 4685
packaging: follow hg's supported python version (>= 2.7) "Mercurial 4.3 and newer require Python 2.7." (From https://www.mercurial-scm.org/wiki/SupportedPythonVersions) Also add X- prefix, because that's the correct form, apparently. This line can also be removed in future, since "When Debian supported multiple Python versions, X-Python-Version was used, but it is obsolete now as no supported Debian release supports anything other than python2.7." (From https://wiki.debian.org/Python/LibraryStyleGuide) That page also mentions "X-Python3-Version".
Thu, 13 Jun 2019 13:19:44 +0800 packaging: require hg 4.5 also for usage, not just for building stable
Anton Shestakov <av6@dwimlabs.net> [Thu, 13 Jun 2019 13:19:44 +0800] rev 4684
packaging: require hg 4.5 also for usage, not just for building
Tue, 11 Jun 2019 10:04:11 +0200 packaging: require mercurial >= 4.5 stable
Philippe Pepiot <philippe.pepiot@logilab.fr> [Tue, 11 Jun 2019 10:04:11 +0200] rev 4683
packaging: require mercurial >= 4.5 Otherwise building the doc package fails with: (third party extension evolve requires version 4.5 or newer of Mercurial; disabling) Exception occurred: File "/usr/lib/python2.7/dist-packages/mercurial/help.py", line 624, in help_ raise error.Abort(msg, hint=hint) Abort: no such help topic: evolve
Sat, 08 Jun 2019 16:03:05 +0530 evolve: clarify why returning by adding inline doc
Sushil khanchi <sushilkhanchi97@gmail.com> [Sat, 08 Jun 2019 16:03:05 +0530] rev 4682
evolve: clarify why returning by adding inline doc
Sat, 08 Jun 2019 15:59:31 +0530 evolve: move a code block to have right value in has_some_val
Sushil khanchi <sushilkhanchi97@gmail.com> [Sat, 08 Jun 2019 15:59:31 +0530] rev 4681
evolve: move a code block to have right value in has_some_val Because of this we were having wrong value of has_some_val and had some buggy behavior which is being fixed by this patch. Fixed behavior is reflected by the changes in test file.
Sat, 27 Apr 2019 13:09:34 +0530 topic: add tests which demonstrate topicset failure of FilteredRepoLookupError
Sushil khanchi <sushilkhanchi97@gmail.com> [Sat, 27 Apr 2019 13:09:34 +0530] rev 4680
topic: add tests which demonstrate topicset failure of FilteredRepoLookupError When topics are used, it fails to find hidden revs mentioned in a revset as we are not using unfiltered view of repo. Next patch will fix it.
Sat, 08 Jun 2019 16:57:34 +0800 pick: reduce configoverride() scope
Anton Shestakov <av6@dwimlabs.net> [Sat, 08 Jun 2019 16:57:34 +0800] rev 4679
pick: reduce configoverride() scope Merge tool is only needed for merge.graft() (it's what graft in core hg does), so let's make the scope of the ui.configoverride() narrower.
Sat, 08 Jun 2019 16:09:37 +0800 evolve: correct action verb in a message
Anton Shestakov <av6@dwimlabs.net> [Sat, 08 Jun 2019 16:09:37 +0800] rev 4678
evolve: correct action verb in a message
Sat, 08 Jun 2019 16:06:24 +0800 evolve: internationalize a message
Anton Shestakov <av6@dwimlabs.net> [Sat, 08 Jun 2019 16:06:24 +0800] rev 4677
evolve: internationalize a message This exact message was already wrapped in _() in the same file, just not here.
Thu, 06 Jun 2019 17:37:42 +0800 evolvecmd: the proper way to deal with conflicts is to resolve them
Anton Shestakov <av6@dwimlabs.net> [Thu, 06 Jun 2019 17:37:42 +0800] rev 4676
evolvecmd: the proper way to deal with conflicts is to resolve them And it's worth making the suggestion an actual hint.
Wed, 05 Jun 2019 17:56:44 +0200 test-compat: merge mercurial-4.5 into mercurial-4.4 mercurial-4.4
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 05 Jun 2019 17:56:44 +0200] rev 4675
test-compat: merge mercurial-4.5 into mercurial-4.4
Wed, 05 Jun 2019 17:46:06 +0200 test-compat: merge mercurial-4.6 into mercurial-4.5 mercurial-4.5
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 05 Jun 2019 17:46:06 +0200] rev 4674
test-compat: merge mercurial-4.6 into mercurial-4.5
Wed, 05 Jun 2019 17:45:45 +0200 test-compat: merge mercurial-4.7 into mercurial-4.6 mercurial-4.6
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 05 Jun 2019 17:45:45 +0200] rev 4673
test-compat: merge mercurial-4.7 into mercurial-4.6
Wed, 05 Jun 2019 17:42:50 +0200 test-compat: merge mercurial-4.8 into mercurial-4.7 mercurial-4.7
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 05 Jun 2019 17:42:50 +0200] rev 4672
test-compat: merge mercurial-4.8 into mercurial-4.7
Wed, 05 Jun 2019 17:39:32 +0200 test-compat: merge mercurial-4.9 into mercurial-4.8 mercurial-4.8
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 05 Jun 2019 17:39:32 +0200] rev 4671
test-compat: merge mercurial-4.9 into mercurial-4.8
Wed, 05 Jun 2019 17:38:32 +0200 test-compat: merge stable into mercurial-4.9 mercurial-4.9
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 05 Jun 2019 17:38:32 +0200] rev 4670
test-compat: merge stable into mercurial-4.9
Fri, 07 Jun 2019 02:25:02 +0200 branching: merge with 9.0.0
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 07 Jun 2019 02:25:02 +0200] rev 4669
branching: merge with 9.0.0
Fri, 07 Jun 2019 02:24:08 +0200 branching: merge back with stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 07 Jun 2019 02:24:08 +0200] rev 4668
branching: merge back with stable
Fri, 07 Jun 2019 02:22:05 +0200 packaging: mark as development versions stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 07 Jun 2019 02:22:05 +0200] rev 4667
packaging: mark as development versions This help to distinct official release from in progress work.
(0) -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 tip