branching: merge with stable

obshashrange: force saving of stablesort and firstmerge cache For some reason the check in repo is not working for stable sort. We also force firstmerge to be saved as test show it was missing.

test: add a test about cache warming This test reveal that multiple cache are not saved to disk after discovery (firstmerge, stablesort).

stablerange: save stablesort cache alongside the stablerange one This one does not introduce inconsistency but helps performance. G: changed hgext3rd/evolve/stablerangecache.py

obshashrange: always save stable range cache alongside the obshashrange one If the on disk date cover different area, the invalidation of affected range will misbehave.

obshashrange: clear in-memory cache alongside the sqlite one Clearing on disk data in nice, but we also need to remove in memory one or we'll get incorrect results.

branching: merge with fixes on stable

changelog: summarize the recent improvement

obshashrange: re-enabled more selective pruning of affected range

obshashrange: fix computation of affected ranges The computation of impacted nodes and associated revs is fully reworked. In addition,we introduce multiple new tests covering cases that were previous wrongly handled.

obshashrange: add more validation output to tests We are about to update the logic and add more tests.

obshashrange: correctly detect changeset directly affected by prune Before this changesets, parent of standard obsmarkers were wrongly considered affected and pruned changeset were wrongly not considered affected.

obshashrange: do not search for affected ranges above the highest we have It is a fast way to know we don't have an affected range for an affected revision.

obshashrange: do not search for affected stable range cache is unavailable Before this changeset we where resetting in all cases, and then looking for affected ranges. In addition is the stable range were not available, the functions silently returned no ranges affected. Now, do one or the other depending of the availability of the stable range cache. In practice we always do a broad reset because the code detecting affected changeset is currently buggy.

stablerange: build closure a bit less inefficiently The new way make me a bit less sad than the old one.

discovery: make sure repository wrapping happens in the right order Otherwise we may end up in situation were cache are not warmed in the right order, crashing.

branching: merge with stable

changelog: add an entry about the next --evolve fix

changelog: update 8.1.0 release date

next: fix topic constraint in the --evolve case We were using the wrong variable.

next: use set for membership testing There are no reason to use a list here.

test: adapt to core output change on unknown command CORE-TEST-OUTPUT-UPDATE: 5199c5b6fd29

compat: use new style template keyword declaration

test: fix previous changeset output The previous changeset got published prematurely.

obshashrange: add a test for `hg debugupdatecache` It seem to be properly filling the caches.

branching: merge with stable

templatekw: do not override in-core {obsolete} keyword The extension version uses old API, which will be deprecated in Mercurial 4.8.

packaging: mark version as development version This avoid confusion when installing non-tagged version.

Added tag 8.1.0 for changeset 2c5d79c6459c

packaging: prepare version

branching: merge stable into default

test-compat: merge mercurial-4.4 into mercurial-4.3

test-compat: merge mercurial-4.5 into mercurial-4.4

test-compat: merge mercurial-4.6 into mercurial-4.5

test-compat: merge stable into mercurial-4.6

compat: fix obslog compatiblity with 4.3 Due to the way of how successor sets are retrieved in new Mercurial version, retrieving it again in 4.3 way would be a performance hit and complexify the code too much. Don't retrieve markers of successor sets which makes obslog filtered output more limited in 4.3.

compat: add a fixed version of mergecopies for hg<=4.3 In hg<=4.3, copies._fullcopytracing() does not exist and we have to wrap copies.mergecopies() to fix the AssertionError coming from core.

test-compat: merge mercurial-4.5 into mercurial-4.4

test-compat: merge mercurial-4.6 into mercurial-4.5

test-compat: merge stable into mercurial-4.6

compat: make compatible call to ui.edit for hg <= 4.3 This is similar to what is already happening elsewhere.

compat: ignore extra status feature for hg <= 4.3 The feature does not exist in 4.3 and below.

format: fix indentation level Previous change got pushed without the fix by mistake.

test-compat: merge mercurial-4.6 into mercurial-4.5

test-compat: merge stable into mercurial-4.6

compat: disable empty topic warning on `hg phases` for hg <=4.5 This is annoying to support for lower version.

compat: restore compatibility with Mercurial <= 4.5 The __init__ arguments changed a lot in 4.6 and 4.7, lets do be as transparent as possible

test-compat: merge stable into mercurial-4.6

test-compat: merge stable into mercurial-4.6

branching: merge stable back into default

compat: improve detection of Mercurial 4.6 fixed case where AttributeError can be thrown when importing wireproto

cleanup: use NotImplementedError instead of NotImplemented Caught by pyflakes.

CHANGELOG: add some entries and remove duplicated entries

branching: merge default into stable The stable branch of Mercurial core now contains Mercurial 4.7 so evolve branch policy requires this merge. The @ bookmark is in the right location, so people doing clone will get to the latest release.

branching: merge with the other head

test-compat: backed out changeset 8fe8152ff071 These output change were for 4.7 only.

test-compat: backed out changeset 41fc764bf28c These output change are for mercurial-4.7 only

test-compat: backed out changeset dda5b2134b32 These change were for Mercurial 4.7 only.

test-compat: backout change to 1e103c7f7663

compat: use older API for older version This API changed in 4.7, we need to adjust.

branching: create mercurial-4.6 branch for updated test output This branch will be used to check for 4.6 compatibility.

builddependencies: extract function for getting successors The code no longer makes a difference between single- and mult-successor cases and just needs a set (or generator, really) of successors to iterate over. Let's extract that into a function.

builddependencies: share code between single- and multi-successor cases The two cases now have more similar structure ("if succ in revs: dependencies[r].add(succ)"), so let's share the code so it doesn't start drifting apart again.

builddependencies: build inverse dict from forward dict It's error-prone to keep "dependencies" and "rdependencies" in sync (we don't do it correctly when there are multiple successors or a node). It's easier to just create "rependencies" from "dependencies" after it's complete.

builddependencies: remove a use of defaultdict I don't see much reason to make "rdependencies" be a defaultdict when "dependencies" is not. It's easy to initialize each entry ourselves.

branching: merge with stable

builddependencies: don't remove found deps when divergence found (issue5946) It seems obviously wrong to not keep any dependencies for a revision that we had already found (for p1) if we run into divergence (from p2). It also happens to fix issue5946 :)

builddependencies: don't add dependency on revision outside input set This was already handled in the single-successor case, but had been missed in the multiple-successors case. Note that there seems to be a copy of builddependencies() in the topics extension. I don't use topics more than I have to, so I'll let someone else fix that code.

builddependencies: consider all divergent successors We were only considering one. In test-evolve-abort-conentdiv.t:165, the input revs were {5, 8} and dependency dict was {8: set([]), 5: set([10])}, which is a little weird (10 is not in the input set). It still worked because the callers used it (they seemed to only care if there were *any* dependencies). This patch fixes the issue by considering all successors. That means the dependency dict will be {8: set([]), 5: set([8, 10])} after this patch. The next patch will remove the 10 from that set.

tests: add test for issue5946 The test case is a copy of the one for 5833. The only difference is that the merge parents are recorded in the opposite order (and that the test is truncated because it fails).

obslog: check filtered output with folded changesets

obslog: check filtered output with splitted changesets

obslog: check filtered output with pruned changesets

obslog: check filtered output with amended changesets

tests: add a content-divergent obshistory test

tests: extract the obshistory amend then fold test case into a separate file

tests: extract the content-divergence test case into a separate file

tests: extract the obshistory fold test case into a separate file

tests: extract the obshistory lots of split test case into a separate file

tests: extract the obshistory split test case into a separate file

tests: extract the obshistory prune test case into a separate file

tests: extract the obshistory amend test case into a separate file

tests: extract obshistory setup in a separate file We are gonna soon explode the obshistory test file into several, extract the setup to reuse it as much as possible.

obslog: add a new flag to filter out non-local nodes

compat: drop compatibility hack for mercurial <4.3 We no longer support version prior 4.3.

compat: temporarily move copies fix to compat.py This patch moves a fixed version of copies._fullcopytracing() to compat.py as this was not fixed in core before release and also we need to do this anyway for the older versions of mercurial. This fix is that when base changeset is not ancestor of any of the merging commits, we don't throw an error. The phabricator differential which will fix this in core is https://phab.mercurial-scm.org/D3896. This fixes the traceback we get in previous changeset while relocating one of the content-divergent changeset.

evolve: continue conflicted relocation content-divergence This patch adds logic to continue an conflicted content-divergence resolution which was interrupted while relocating one of the divergent commits. The tests shows the there is some mishandling of copies internally which will be fixed in next patch.

topic: use self instead of repo in topicrepo methods Referring to repo here was somehow preventing it from being garbage-collected (important in hgweb, where currently every request gets a new repo).

evolvecmd: introduce fn to be wrapped by extensions resolving content-div The function added will be used by extension by wrapping it and adding logic to merge data introduced by them. For example: topic extension can wrap this function and add logic to merge topic names.

evolvecmd: move remaining logic to merge commit desc to existing utility fn This was a bit awful because we had a utility function and still we did some of merging outside of that fn. So let's move the remaining parts there.

amend: allow aborting an `amend --patch` by saving an empty file (issue5925) This patch fixes issue5925 by allow aborting a `hg amend --patch` call by saving an empty patch file. This is similar to aborting of `hg amend` when commit message is empty. Test changes demonstrate the fix.

tests: add a test to demonstrate issue5925 The issue will be fixed in next patch.

test: fix possible output change from 4.7 Change in debug timing can display these extra messages.

state: add the get() method that evolvecmd:1836 expects

rewing: prevent rewind in case of uncommitted changes rewind can update, which means merge and troubles. We might relax this limitation in the future.

rewind: default to rewinding the current stack

rewing: add the ability to rewind "from" revisions

evolve: exclude "identical" precursors from the precursors set I'm not sure it is the right thing to do, but it simply thing a lot for now. Otherwise, using 'precursors' to find rewind direction become too complex. This is going to give problematic result in case of prune. Since there are no other precursors to follow.

rewind: move revision selection into its own function This will help making the logic more advanced.

rewind: automatically rewind entire stack We now rewind the full stack, avoiding creating orphans. A `--exact` flag is added to force rewinding only the explicitly specified changesets.

rewind: add a test about rewinding top of stack For now this rewind is creating an orphan. We add the test to check the behavior in that case.

rewind: use rewinded parent when creating multiple changesets Use use the rewinded parent instead of creating orphans based on identical, but obsolete, changesets.

rewind: add a test for rewinding a fold The code already have basic support for case. However the result create orphan that will need to be improved. However, we keep this changeset simple.

rewind: add a test for rewinding a split There are no code change needed but it is worth testing on its own.

rewind: update the working copy if it gets obsoleted If the working copy parent is rewinded, follow the rewind.

rewind: add a message about obsolete changeset Not the best output, but useful to have the data. We can improve that later.

rewind: obsolete latest successors unless instructed otherwise To prevent the creations of divergence, we automatically mark the successors set of the rewinded changeset as obsoleted by the rewind result. A new flag `--as-divergence` is added to disable this behavior.

rewind: test rewinding an amended changesets We are now able to rewind a simple amended changeset. For now, its current successors has not been obsoleted and we created divergence.

rewind: add a message about the rewinded changesets This helps to understand what happened.

rewind: add a proto version of the command This first version focus on rewinding a single revision without care for the consequence.

stablesort: make sure heads are processed in sorted order changeset 72621094505f will fix some ordering issue in the `heads` revset so we stabilise the output in advance.

evolve: move the bookmarks also when updating to successor (issue5923) When we are on an obsolete node and does `hg evolve`, it updates to it's sucessor, however it does not move the bookmark to the successor. This patch adds logic to make sure we move the bookmark too. Test change demonstrates the fix.

tests: add test to demonstrate issue5923 This will be fixed in upcoming patch.

changelog: add an entry about the new `evolve.interrupted` section

evolve: make one missed error to align other error messages Previous patches missed this error to change it to the new format. Let's align this with all other messages raised by `hg evolve` command.

evolve: raise error.InterventionRequired instead of Abort when conflicts error.InterventionRequired is a better error to raise in such cases. Thanks to marmoute for noticing this.

changelog: add a changelog entry about divergence resolution We made a lots of progress there.

evolve: create resolved cset on successors of current parents While resolving content-divergence, sometimes, the parent can be obsolete and have a successor. We should consider the successors of the parents instead of obsolete parents as that will do something like orphan+content-divergence resolution both at the same time which is powerful and results in a single stack while resolving content-divergence of stacks. The test changes demonstrates that we can now successfully evolve a content divergent stack.

tests: fix a test case to not create conflicts This is the test case where we are testing about divergence resolution of stack of patches. If the stack is as follows: C1 C2 | | B1 B2 | | A1 A2 \/ base And A1-A2, B1-B2 and C1-C2 are content-divergent, and merging A1-A2 results in conflicts. Now if you resolve conflicts and continue resoling B1-B2, the conflicts of A1-A2 will still be there. We need somehow to understand the work we has done and not create conflicts again. To test the evolution functionality for now, we make sure conflicts does not occur.

evolve: introduce a resolutionparent variable and store it in evolvestate This patch introduces a resolutionparent variable which will be the parent of final changeset after resolving content-divergent changesets. Till now, the parent is always the parent of one of the divergent node, but now in upcoming cases, it can be a successor of both the parents of divergent nodes.