evolve: add test which shows orphan-merge resolution can result to crash It happens when there are still some revisions to evolve after evoluiton of a orphan-merge. And the reason behind crash is that `lastsolved` is not being updated and contain a wrong value which is now hidden. Next patch will fix this problem.

next: populate stacktemplate to the missed _nextevolve function

evolve: adapt for deprecated ui.progress() This makes a wrapper that has an interface like ui.progress() even though that's the old interface that will eventually go away. That's because it's a lot easier to convert from the ui.progress() to the ui.makeprogress() interface than the other way around. Once we no longer support hg<4.7, we can migrate our callers to ui.makeprogress() and drop the wrapper.

fold: sort concatenated commit messages in topological order It seems better to have the proposed commit message look the same whether the user ran `hg fold --exact -r . -r .^` or `hg fold --exact -r .^ -r .`.

topic: make revsets like 'foo#topic[0]' work Essentially, 'topic' relation subscript function is the same as 'generations', but is limited to revisions marked with one particular topic.

changelog: add an entry about the revset stack indexing

test: adapt output to minor behavior change CORE-TEST-OUTPUT-UPDATE: bad05a6afdc8

tests: remove unused variable and needless subshell in testlib/pythonpath.sh

branching: merge with stable

tests: conditionalize some output for Windows A couple of these were already present, but out of place.

test-pyflakes: use '/' when printing the files to check If paths are printed with '\', `xargs` sees the parts allsmooshedtogether, and pyflakes errors out.

tests: fix PYTHONPATH manipulation on Windows Without the semicolon separator and quotes, the variables ends up like this: c:\Users\Matt\projects\hg-evolve:c:\Users\Matt\projects\hg-evolve: c:\Users\Matt\projects\hg;c:\Users\Matt\projects\hg-evolve\tests; c:\Users\Matt\projects\hg\tests That in turn makes the local evolve code unreachable, and the system installed code is tested instead. I'm testing against `uname` instead of a trivial python script printing os.name because maybe one day tests will run on WSL.

exthelper: update documentation with some examples for using registrar aliases

exthelper: simplify the ability to register filesets Same mechanism as revsets earlier in this series.

exthelper: simplify the ability to register templates Same mechanism as revsets earlier in this series.

exthelper: simplify the ability to register revsets I think this is what Yuya and Boris agreed on.[1] This happens *after* the extsetup phase now (and after the _aftercallback notifications). But this is trivial, mergeable between exthelper instances, and doesn't need to have the extension name supplied when registering. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-December/125888.html

exthelper: support the option argument when registering a command Largefiles uses this 5th argument with push and pull, so this will be tested in the next commit. I assume the reason for unrolling and reforming the tuple in each finalxxxsetup() is to validate that something proper was passed in when registering. But it's better to explode when decorating than during the delayed actual registration.

exthelper: simplify configitem registration

exthelper: avoid a [] default arg to wrapcommand()

configitems: move the default values to the registrar decorator The exthelper refactoring of configitems stopped registering dynamicdefault for everything, which in turn causes a lot of warnings about mismatched defaults. There are a few stragglers- I didn't fix topic-mode because I wasn't sure what the default should be, and the alias for odiff was explicitly given a default for compatibility.

topic: make revsets like foo#stack[-1] work too We remove base commit when n < 0 because it's confusing to see base (which technically isn't a commit inside the stack) at both 0 and -n.

topic: make revsets like 'foo#stack[0]' work 'stack' relation subscript function is another way to refer to s0, s1, etc. But instead of aborting in many cases it will simply return an empty set.

exthelper: remove '_' in final_xxx() function names to conform to hg style

branching: merge with stable

packaging: mark as development version This avoid confusion when installing from source.

Added tag 8.3.3 for changeset 97b18934d6db

packaging: prepare version 8.3.3

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 mercurial-4.7 into mercurial-4.6

test-compat: merge stable into mercurial-4.7

evolve: detect unresolved conflict during evolve --continue (issue5966) Evolve --continue was ignoring unresolved conflict, proceeding with its operation without any check. This is now fixed. This test case was built and formalized by Matt Harbison and Anton Shestakov.

tests: filter out uninteresting log events Core has new ui.log() calls added (for tracking extension loading and performance, for example), but in test-discovery-obshashrange.t it produces a bunch of lines that are unrelated to the test. So we filter them out to not touch test output. This is inspired by 1de3364320af in core.

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 mercurial-4.7 into mercurial-4.6

test-compat: merge stable into mercurial-4.7

linter: silence rightful complains about unused variable

topic: merge _showlasttouched logic into _listtopics Makes --age work with --verbose.

topic: simplify _showlasttouched and _getlasttouched (and its data structure)

branching: merge with stable

split: add a --interactive flag While the interactive mode is useful for end-users, there are some cases where they don't need the interactivity overhead. Moreover, this allow the split command to be used in automated scripts.

split: take file patterns to limit selection on matching file patterns When splitting a big changeset, the user often wants to extract specific files from the changeset while leaving the others files intact. The split command can now be called with multiple file patterns. Only files that match one of the patterns will be shown in the interactive selection. The user will be able to create one or more commits with those files. When the user finishes splitting the matching files, a last commit will be made with the remaining of the files.

split: only accept explicit revision through the `-r` option We are about to introduce new non-optionnal arguments to defines files patterns. To avoid confusion and to be closer to the standard options, only accepts revisions with the `-r` option.

issue-6028: resolves 6028 - return (False, ".") instead of (False, '') Since 4.8, repo[] no longer takes an empty string, so we update to a valid with similar semantic. This value is strange and we should probably use an actual node ID here, however, this is an independent issue.

branching: merge with stable

tests: add sparserevlog cap since hg now has sparse revlogs by default CORE-TEST-OUTPUT-UPDATE: 3764330f76a6

split: rework the prompt to be more standard We dropped the initial capital and moved to a positive question.

split: add a option to discard remaining change during split This is useful to drop unwanted remaining change spotted during the split.

split: add a way to abort a split from the prompt This prompt is asking the user about the next step. Offering to abort there make sense.

split: add a help entry to the final prompt We are about to add more option in this prompt. Adding a way to document then seems like a good first step.

topic: make revset argument messages be similar to such messages in core

tests: don't forget to add hg serve pid to DAEMON_PIDS in test-wireproto.t Otherwise it leaves a process running after each run-tests.py launch.

test: adapt to change output change on default We now have a `wcache` directory in `.hg`.

safeguard: don't reimplement auto-publish if it's in core (will be in 4.9)

safeguard: the new default for auto-publish is 'publish'

stack: add a --children flag to stack If a commit in the stack has been merged outside the current topic, show a trailing status of (external-children)

extensions: avoid shadowing imported module names with exthelper methods The previous code worked, but confused pyscripter.

extensions: add fileset support to exthelper This will be tested by using it in lfs.

extensions: add uipopulate() support to exthelper

exthelper: clarify copyright and licence for the module The exthelper is quite useful and Matt Harbison is looking into having it upstreamed. We clarify the legal situation first.

packaging: merge with version 8.3.2

packaging: mark development version This help reduce the confusion when people install from source.

Added tag 8.3.2 for changeset 7edc5c148df0

packagin: prepare release 8.3.2

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 mercurial-4.7 into mercurial-4.6

test-compat: merge stable into mercurial-4.7

changelog: add information about the topic message improvements

branching: merge with stable

evolve: update the abort to a ProgrammingError This error should be a ProgrammingError and as Pierre-Yves David said ProgrammingError type did not existed when this code was written, so lets update this now.

topics: improve the message around topic changing The new message says 'cleared' when topic name is cleared, if we change to a new topic name, it mentions the new topic name too.

tests: fix for POSIX compliance * Mac ls will exit with a different message and exit code [1], replace with grep (which is what mercurial tests do) * POSIX echo has no -n switch, use printf instead

style: remove unused variables Both `as e` references are not used and can go.

evolve: fix a documentation typo

compat: drop 4.3 related obsfate code All the necessary piece are supported starting 4.4.

compat: drop code dealing with incompatibility for --publish with 4.3 We dropped 4.3 support.

compat: clarify when some conditional are used The middle condition was an intermediate state that never existed into a release. We can safely drop it.

compat: drop 4.3 "new troubles" report code This is supported natively for Mercurial 4.4 and above.

compat: drop 4.3 wrapping of createmarker for effect flag support This is supported natively in 4.4 and above.

compat: drop 4.3 monkey patch of `copies.mergecopies`

compat: drop 4.3 compatiblity code for `obsutil.allprecursors` function

compat: drop 4.3 compatiblity code for `ui.edit` method

compat: drop 4.3 compatiblity code for 'successors' revset

compat: drop 4.3 compatiblity code for 'precursors' revset

compat: drop Mercurial 4.3 support for exthelper The last release email noted plans to drop 4.3 and 4.4 support in the next feature release. I'd like to move this code into core, and dropping this should allow the class to be copied in unmodified.

compat: update metadata about minimum ag version

next: solve the issue of `next` get confused by split This patch solve a problem of next command which get confused by split. Let me describe how it was getting confused: Initial state of repo: A---B---C After splitting B to (B1,B2): @ A---B1---B2 \ ---B---C X * (note: C is orphan; checkedout to B1) Lets make an amend on B1: @ B1' / A---B1---B2 \ X * \ ---B---C X * Now, if run `hg next` (--evolve is True by default now): $ it would give you choice to choose from B2 and C thinking that C could also be a possbile children for B1, instead of stablizing B2 on B1. I fixed this problem by filtering those aspiring children which can be stablized on one of the aspiring children itself. Changes made in test-prev-next.t shows the changed expected behaviour.

next: add test which shows that `next` get confused by split

cleanup: avoid a Yoda condition

evolve: modify and move the comment to appropriate position

next: update the command description Now, if necessary next command evolve the next child revision by defualt. You don't need to pass the --evolve flag.

next: make next command --evolve by default Before this patch, if we need to evolve to update to the next child, we were suggesting the user to use --evolve flag. This patch make some changes to evolve by default in that conditions. After making next command to evolve by default we have to consider the following points: 1) If we don't need to evolve while updating to the next child: a) And if wdir is dirty, we suggest to use --merge flag b) if wdir is clean, we simply update to next child (if ambiguous, prompt the user to select one) 2) If we need to evolve: a) when wdir is dirty, we suggest the user to use `hg shelve` first, to make wdir clean. As we don't support --merge while evovling. b) when wdir is clean, we evolve the next cset. Changes made in test-prev-next.t reflect the changed behaviour.

safeguard: allow push to succeed (and without warning) with --publish

topic: only add --publish flag to push if it's not already there

safeguard: check auto-publish value before sending listkeys command Always sending listkeys command is just wasteful, let's first make sure users even care about auto-publish behavior.

style: silence another flak8 warning Default should be green now.

oops: backed out changeset df22f010cf24 pushed by error The changeset still fails some test

next: make next command --evolve by default Before this patch, if we need to evolve to update to the next child, we were suggesting the user to use --evolve flag. This patch make some changes to evolve by default in that conditions. After making next command to evolve by default we have to consider the following points: 1) If we don't need to evolve while updating to the next child: a) And if wdir is dirty, we suggest to use --merge flag b) if wdir is clean, we simply update to next child (if ambiguous, prompt the user to select one) 2) If we need to evolve: a) when wdir is dirty, we suggest the user to use `hg shelve` first, to make wdir clean. As we don't support --merge while evovling. b) when wdir is clean, we evolve the next cset. Changes made in test-prev-next.t reflect the changed behaviour.

next: improve the message for dirty working copy with --evolve This will be important soon when --evolve will be the default.

next: use the `hint` argument of bail if changed The argument is availabel since Mercurial 4.1. So let's use it.

prev: use the `hint` argument of bail if changed The argument is availabel since Mercurial 4.1. So let's use it.

next: explicitly specify --no-evolve in the tests The default value for this flag is about to switch.

branching: merge with stable

style: fix various flake8 warning

next: set if we need to evolve or not; also move logic to appropriate pos set the value `needevolve` and also move the logic to find aspiringchildren to appropriate position i.e before we suggest user to use other flags like --merge.

next: move some code to prepare for `next --evolve` by default Moved some values before the block where we suggest the user to use --merge flag. As we would need these values to find if we need to evolve or not before we can suggest user to use `--merge` flag. We will suggest user to use `--merge` flag only when we don't need to evolve. Because currently we don't support both --evolve(going to be True by default) and --merge at the same time.

branching: merge with stable

topic: improve UX by using pager only when we should Before this patch we were using pager in every case of topic command, either it is setting up a new topic or clearing the active topic. After this patch it will not use pager in following commands: $ hg topic [TOPIC] -r [rev] $ hg topic --clear

evolvecmd: _possibledestination() skip visiting empty parent I see that even in the case when "parent == -1" we are visiting that also and find succsets for that and in last -1 is being added in the set of possible destination. Why not skip that?

pick: `hg help` was not showing the full cmd desc of `pick` after running command `hg help` it was not including the second line of command description. I guess it picks the firstline only. So I moved that part in first line of cmd description.

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 mercurial-4.7 into mercurial-4.6

test-compat: merge stable into mercurial-4.7

compat: fix fixedcopytracing compatibility with mercurial 4.8 and narrow Mercurial 4.8 version of _fullcopytracing includes some new narrow code. As https://phab.mercurial-scm.org/D3896 has not yet landed, update fixedcopytracing behind a version detection condition. This was spotted by Augie Fackler.

utility: don't translate commit messages in revselection prompt (issue6016) Commit messages should not be translated and should be shown the same. I am not sure if I can add a test for this by creating a commit with non-ascii character in commit message.

evolve: use stack template in --continue case also We use stack indexes (s#) in evolve msging when revs being evolved are in active topic. Before this patch we are not covering the --continue case. So this patch cover the same and use the stack indexes s# even when we continue an interrupted evolve. In this patch I used the same concept (to check if we should use s#) as we are using in cases other than `--continue`. Thanks to PYD for refactoring those lines. Changes in tests also reflects the expected behaviour.

evolve: add test showing currently stackalias fails in --continue case

branching; merge with stable

packaging: mark version as devel version This avoid confusion from people installing from source.

Added tag 8.3.1 for changeset b90422a11a88

packaging: prepare version 8.3.1

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 mercurial-4.7 into mercurial-4.6

test-compat: merge stable into mercurial-4.7

evolve: do not try to display stack index of changeset who do not have one

evolve: check if we should use stack template for each item in the stack We should probably just track the current topic and move all the logic in the template itself. However, this is a good first step.

branching: merge stable back 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 mercurial-4.7 into mercurial-4.6

test-compat: merge stable into mercurial-4.7

branching: revert test outptu change for 4.7

pullbundle: drop erroneous flagging of the command as basic This is a debug command, not a basic part of the UI.

test-compat: backed out changeset ba1e83c841f2 Preparing the branch for 4.8.

test-compat: backed out changeset b0084d599112 Preparing the branch for 4.8.

test-compat: backed out changeset e2d083cc447e Preparing the branch for 4.8.

test-compat: backed out changeset ccbfbeee6cf3 Preparing the branch for 4.8.

test-compat: backed out changeset 7091f7215651 Preparing the branch for 4.8.

test-compat: backed out changeset 8eec9422bd8e Preparing the branch for 4.8.

branching: merge stable into default

branching: start test compatibility branch for Mercurial 4.7 Mercurial 4.8-rc0 have been released

topic: add the changelog argument to branchinfo() 47c03042cd1d in core added a changelog argument to revbranchcache.branchinfo() and we wrap that function in topic extension. So let's add this optional argument in topic extension too.

evolve: adapt for changed @command decorator Core changed the hacky "^command" syntax to be a proper decorator option in fa88170c10bb (help: adding a proper declaration for shortlist/basic commands (API), 2018-10-12). This patch makes evolve compatible with that.

topicidx: stop assigning index number to obsolete changesets Obsolete changeset are no longer part of the stack, the old logic tried to assigns them the index of their successors but this is flacky and error prone. So we stop doing so.

stack-index: add some test featuring content diversion This will be useful to display various issues.

pullbundle: drop erroneous flagging of the command as basic This is a debug command, not a basic part of the UI.

topic: add the changelog argument to branchinfo() 47c03042cd1d in core added a changelog argument to revbranchcache.branchinfo() and we wrap that function in topic extension. So let's add this optional argument in topic extension too.

topics: "prairie" is a not an animal (AFAIK, anyway)

tests: remove a"| head -n 2" that just hides an error code The output from core used to be longer and it made sense, but no longer does. CORE-TEST-OUTPUT-UPDATE: 5199c5b6fd29

evolve: adapt for changed @command decorator Core changed the hacky "^command" syntax to be a proper decorator option in fa88170c10bb (help: adding a proper declaration for shortlist/basic commands (API), 2018-10-12). This patch makes evolve compatible with that.

commands: adjust metavariables as appropriate Apart from looking better in hg help command, these strings are also helpful when generating shell completions programmatically.

branching: merge with default

branching: preserve the expected output on default

evolvecmd: use modern vocabulary in help text for evolve

evolvecmd: mark flags with old instability names as deprecated

packaging: mark as development version

Added tag 8.3.0 for changeset 45d4b49d81d9

packaging: prepare release 8.3.0

pullbundle: document working version and update changelog to mention it

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

topic: fix '{topicidx}' keyword registration for mercurial <= 4.5

branching: prepare release 8.3.0

test: other harmless output change These are new test that need adjustment for 4.7 output.

changelog: mention the fix of cache warming on hg strip

test: backed out output changes from changeset 6f391c2a773b

test: backed out test output changes from changeset ef22eef37ecc

test: backed out output changes from changeset 0171a7ceb574

test: backed out output changes from changeset dfa69b5ece87

test: backed out output changes from changeset 01ad46551d7c

prev: also use stack shortcut in output when possible This mirror what `hg evolve` is doing since cc3a0b13ae57.

next: also use stack shortcut in output when possible This mirror what `hg evolve` is doing since cc3a0b13ae57.

branching: merge stable into default

rewind: alias the command to undo This is a step in unifiying rewind and undo and not talk about them as different commands or concepts. If there exists rewind command, that should be an alias of undo and the vice versa. The exact implmentation detail and how the command works etc. is a different thing but there should be just one command.

changelog: add a line about the usage of s# in evolve

caches: no longer warm the cache on strip in "auto" mode Before this patch, a strip would trigger a full and blind cache load that would include the stablerange cache. In repository like Mozilla this was a bit painful. The default "auto" mode now behave has intended.

evolve: use stack alias s# in `hg evolve` msgs As repository grows revision number lose their usefulness. To make it a little better than now, after this patch we will be using short stack aliases introduced by the topic extension (as displayed by `hg stack`). These stack aliases s# will be used only when user has enabled topic extension and his repo's current active topic is same as the revs to be evolved. For now, this patch doesn't cover `continue` case. I will discuss about this with Pierre-Yves David. Maybe we have to store the info in evolvestate that "we were using stack aliases".

evolve: extract displayer to _solveone() I extracted this displayer method to _solveone() so that it would be easy to pass a different template to show evolve msgs. In upcoming patches we will be using stacktemplate in some cases where we want to include stack alias s# in evolve msgs.

utility: add a template alias that will be used in evolve msgs This template use stack alias s# instead of rev number in messages printed when we run `hg evolve`. For example, this template's msgs will look like this: move:[s3] add aaa atop:[s2] add bbb move:[s4] add ccc I will be using this template in upcoming patches.

topic: add topicidx template keyword This keyword will be useful where we want to see the index of the changeset in the stack when we run `hg stack`.

changelog: fix version number

tests: update the test-topic.t with changes in core mercurial Yuya stabilized the -T option and now it's in help by default. CORE-TEST-OUTPUT-UPDATE: 0d703063d0c8

pullbundle: fix style warning

pullbundle: improves management of multiple branch while dealing with a head There were still case where a range was issued too early.

pullbundle: deal with head in a predicable order We use node order to make this repeatable from one clone to another. This is an arbitrary pick.

pullbundle: deal with another special case introduced by arbitrary ranges previous, we dealt with the case where the tippest subrange of the stable parent was too long. Now, we need to deal with the case where it is too small.

pullbundle: compat with Mercurial 4.7

pullbundle: add some information on the cached change This also adds a way to skip "caching" smaller range in the debugcommand (not in the extensions itself).

pullbundle: add data about the cached bundle size and hit

pullbundle: add a command to generate cache hit statistic This new command should help checking that the stable range produce reusable bundle.

pullbundle: point out the output flooding issue from core Right now, we don't have a reliable progress report when using pullbundle.

pullbundle: issue local branches in the right order

pullbundle: delay cache file opening Otherwise we can end-up with a too many file open at the same time.

pullbundle: improve slicing of the lower part of range The previous method could get confuse by merge and overslice. The new method is better at using sticking on power of two boundaries.

stablerange: fix slicing of arbitrary ranges Pull bundle trigger slicing from range with arbitrary initial skip. We have to adjust the current slicing to take this into account.

pullbundle: attempt to save stablerange cache after each computation Since we do not serve the full repository, we use more stablerange starting from a random point. These are probably not loaded yet and should be cached. This is best effort caching, if we can't save them we won't.

pullbundle: add basic extension metadata

pullbundle: add a config option for the cache directory

pullbundle: add an output about the time spent slicing the set This will be useful to monitor overall performance.

pullbundle: add extension documentation

pullbundle: add an extra test showing how cache are reusable We issue a single final pull, most of its item are reusable.

pullbundle: add caching logic We now only generate a bundle once (and store it to disk). If we need it again, we use it directly from disk.

pullbundle: slice pull into multiple ranges We subdivide the set of missing revisions into multiple "range" using the "stable range" data structure. This slicing aims at maximizing the capability of the resulting ranges.

pullbundle: initial commit Right now, we do not do any slicing, but we install the wrapping and the tests.

test: update output to make streamv2 capabilities CORE-TEST-OUTPUT-UPDATE: 4bd6e444c76f

branching: merge with stable

topic: respect preexisting 'topic' value on workingcommitctx Mercurial's core changeset: 6c8ceebce309 revealed an issue. If the creator of a workingcommitctx explicitly assigned a 'topic', it was silently overridden by the current active on. This break import of patch with topic information. We now respect preexisting topic information.

topic: add a compatibility to access transaction's names The attribute was made private in 4024c363cd33.

topic: add a compatibility to access transaction's validator The attribute was made private in ebbba3ba3f66.

evovle: remove redundancy in evolve output Copying the discription of this redundancy issue given by Pierre Yves David: When running `hg evolve` to stabilize orphan changeset output about the currently stabilized changeset is issued. For example: $ hg evolve move:[3] a3 atop:[4] a2 working directory is now at 7c5649f73d11 This output can become quite repetitive when orphan are stabilized atop each other. For example: $ hg evolve --all move:[8] dansk 2! atop:[10] dansk! merging main-file-1 move:[9] dansk 3! atop:[11] dansk 2! In this case it would be smoother to issue: $ hg evolve --all move:[8] dansk 2! atop:[10] dansk! merging main-file-1 move:[9] dansk 3! Since we are moving "dansk 3!" atop the changeset we just stabilized. When adding this be careful that we still want to issue the "atop" message in various cases: 1. first changesets in a stack 2. when the orphan is not stabilized atop previous one 3. when using hg evolve --continue to resume an evolution So, I have made the changes which also respect above listed three points. And changes in tests/test-evovle*.t reflecting the changed behavior.

amend: handle crash before transaction initialization with --patch The `tr` object can be None.

branching: merge with stable

obsdiscovery: adopt to calling convention change Upstream commits 71d83b315778 and abce899c985f changed the calling convention of setdiscovery._takefullsample(). We inspect the signature of the function before calling it so we can pass the proper arguments.

branching: merge stable into default

packaging: mark as development version This avoid confusion when people install version from source.

Added tag 8.2.1 for changeset c6362c4abd69

packagin: prepare release 8.2.1

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

branching: merge stable into default

caches: issue both debug and blackbox log message This increase the odd someone looking for issue will find them.

cmdrewrite: rename variable and move it closer to where it is used Renaming to satisfy pep8-naming linter plugin, which complained on this variable because all-uppercase names are reserved for constants, and constants need to be module-level. This variable is not a good choice for moving up to the module level because it's used only in one place. Additionally, let's have it closer to the place it's actually used to potentially avoid an extra call to _() function (however cheap it may be).

changelog: mention the cache improvements

obshashrangecache: be more paranoid in the errors we catch It seems like there error were already covered. Better safe than sorry.

stablerangecache: be more paranoid in the errors we catch It seems like there error were already covered. Better safe than sorry.

stablesortcache: update the variable tracking on-disk state after write Since we updated the on disk content, we should update that value. In practice the object will likely be discarded after the write, but there is nothing wrong in being more correct.

stablesortcache: ignore permission and OS errors when writing This cache is related to the obshashrange one and we update it lazily by default. This can be an issue when pulling locally from a read only repository that was not configured for a more aggressive cache warming. The raised permission error was uncaught and could crash the whole process. Errors during cache update should not block Mercurial operations.

firstmergecache: update the variable tracking on-disk state after write Since we updated the on disk content, we should update that value. In practice the object will likely be discarded after the write, but there is nothing wrong in being more correct.

firstmergecache: ignore permission and OS errors when writing This cache is related to the obshashrange one and we update it lazily by default. This can be an issue when pulling locally from a read only repository that was not configured for a more aggressive cache warming. The raised permission error was uncaught and could crash the whole process. Errors during cache update should not block Mercurial operations.

depthcache: update the variable tracking on disk state after write Since we updated the on disk content, we should update that value. In practice the object will likely be discarded after the write, but there is nothing wrong in being more correct.

depthcache: ignore permission and OS errors when writing This cache is related to the obshashrange one and we update it lazily by default. This can be an issue when pulling locally from a read only repository that was not configured for a more aggressive cache warming. The raised permission error was uncaught and could crash the whole process. Errors during Cache update should not block Mercurial operations.

obscache: update the variable tracking on disk state after write Since we updated the on disk content, we should update that value. In practice the object will likely be discarded after the write, but there is nothing wrong in being more correct.

obscache: ignore permission and OS errors when writing In practice we always update this cache along side a new transaction, with lock taken so permission issues should not happens. However, staying on the safe side is better. Errors during Cache update should not block Mercurial operations.

obshashrange: force reset if many changes If there is many new markers (or the markers affect many changesets) resetting affected changeset can get slow. A common case for that is then changeset and markers are added in different transaction, (eg: when using clone bundle). When we detect such case, we reset the obshashrange cache, rewarming it should be faster. Here many is arbitrarily set to 10 000. The number might get adjusted.

topic: refactor revset.py slightly Checking both kind == 'literal' and topic.startswith('literal:') seems to be redundant, because of how stringutil.stringmatcher() works.

test: update output to match new `hg verify` reports CORE-TEST-OUTPUT-UPDATE: f1186c292d03

test: update output to match new "pull" phase report CORE-TEST-OUTPUT-UPDATE: 89630d0b3e23

test: adapt to change in revert messages order CORE-TEST-OUTPUT-UPDATE: cb70501d8b71

rewind: fix help text (mostly grammar, but also s/precursor/predecessor)

evolve: fix use of "'%d' % ctx" ctx has not been convertible to int since Mercurial commit 38f480502043 (context: remove basectx.__int__ (API), 2018-02-24). I decided to use "%s" instead to match other similar messages in evolvecmd.py. I also added a space to match the other messages.

stablerange: only issue the message once There is a flag to prevent issuing the long load message multiple time. However, it was never set. This is now fixed

changelog: fix version number

branching: merge back with stable

packaing: mark as development version This help avoid confusion when installing in progress work.

Added tag 8.2.0 for changeset 8d8f08245f97

branching: merge back with stable

packaging: prepare new release

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

topic: rework topic templatekw declaration to be 4.5 compatible again Mercurial prior to 4.5 does not have a requires keyword, so we need a compatibility layer.

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

branching: merge the two stable heads

test-output: backout test output update in 8fcee1e65e29

test-output: backout test output update in 503ae2689df8

topic: update the changelog with the 's#' alias change

topic: update other occurrence of 't0' is 's0' in the code

topic: mention t0 in topic documentation

stack: display 's#' instead of 't#' and 'b#' If we want people to use it, we should display it.

stack: clarify s# error message in case of branch A branch might have a lots of changeset, with all of them public.

alias: allow reference through 's#' We keep the 't#' option, but we hope to be able to deprecate it at some point. We move to 's#' because it refers to `stack` a more generic concept. than topic. In addition, this allows to phase out 'b#' that collide with normal hex-node.

topic-revset: get the list of revset through the official localrepo API This is simpler and faster. In addition we tighter the logic to be used in case of empty topic. We do not need to fall back to revision search.

topic-revset: strictly read string Making a clear distinction between string and symbol passed to topic is important when it comes to empty topic. Filtering an empty topic name is harmless. Searching a non existent revision is not.

test: search for empty topic as a string The reduce the ambiguity in the test to help with the next change.

topic: handle ambiguous arguments to topic() revset These arguments can be interpreted as either string or a revset. The decision is made based on existence of topic with such a name. This matches the behavior of branch() revset. The code needs to know all topics that ever existed in the repo, because some commands report "disappearance" of topics after certain operations, using this revset (e.g. via stack.stack or repo.revs).

topic: handle revsets passed to topic() revset This handles cases when the argument can't be interpreted as a string at all.

topic: handle string argument to topic() revset earlier

topic: prepare to handle non-string arguments to topic() revset

topic: return result early if there are no arguments to topic() revset

obshashrange: enable by default We have been testing this in various placed and specific stress test have been performed. It is time to enable this by default

obshashrange: issue a warning if the cache takes a long time to load The -current- implementation of the obshashrange cache can get slow. This will be fixed eventually, in the mean time we inform people on large repository of what have been going on. Since we are about to enable obshashrange by default, we need to make sure nobody will have an (unexplained) bad surprise.

pick: fix last references of grab in code Grab was still referenced on comments and variable names.

pick: replace `hg grab` invocation in test with `hg pick`

pick: replace "grabstate" with "pickstate"

pick: use "pick" as operation name in obsolescence markers

pick: use "pick" instead of "grab" for various internal API This should not much user visible impact but this is cleaner.

pick: update command output to mention pick instead of grab

pick: rename the grab command to pick Grab is ambiguous with "graft", "pick" match the associated verb in histedit. The "grab" name is preserved as an alias for now.

grab: prefix function with 'cmd' as for the other command in the extension

readme: document the purpose of the evolve extension Another place for the explanation to live.

prune: replace --biject with --pair People have been complaining about `--biject` being to obscure for a while. A recent discussion with Pulkit Goyal and Dan Villiom Podlaski Christiansen produce some new concrete proposal that we liked. We eventually settle on using `--pair`. The `--biject` flag will be kept as an alias for a while.

topic: check that repo.currenttopic is set before using it as an argument repo.currenttopic can be an empty string, which means there's no current topic set. This fact can be used to short-circuit some checks. Also, this avoids passing an empty string as an argument to topic() revset.

test: update output after merge message change CORE-TEST-OUTPUT-UPDATE: f785073f792c CORE-TEST-OUTPUT-UPDATE: a3fd84f4fb38

readme: document the tag we use on output change

branching: merge with stable

packaging: fix debian version numbers

packaging: fix debian version numbers

branching: merge stable into default

packaging: mark in progress work as development version This avoid confusion when people install development version.

Added tag 8.1.2 for changeset f1cde4c97806

packagin: prepare version 8.1.2

obshashrange: force obshashrange invalidation by bumping schema The fix in 8.1.1 deserve recomputing the obs hash range cache. So we bump its schema version to declare the older cache invalid. The other caches, including the expensive stablerange are unaffected.

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

branching: merge with stable

changelog: mention the database robutness fix in the changelog

sqlcache: also catch malformed database error This is apparently another way for sqlite to fail at concurrency.

stablerange: rework saving logic to be clearer and safer

obshashrange: rework saving branching to be clearer and safer

sqlcache: protect read query too Some error (like locked database) can even happens when doing readonly operation. So we protect them too. At that point, it seems that pysqlite3 is not the right tool for this job.

sqlite: fast path when nothing to save If we have no new data to save, we should try to do anything. Doing something concurrently is hard enough. If we can avoid doing it at all that would be great.

sqlcache: initialize meta table last It turns out that pysqlite commit after each table creation. This commit is an hopeless attemps to make the caches more concurrent friendly.

obshashrange: always check in base cachekey against the recorded one Ignoring the check in the none case is just disaster waiting to happens.

stablerangecache: fix output in the drifted case The node were not hex, and the field had different order in the pair. This is now fixed.

sqlcache: also ignore integrity error integrity error can happens when multiple client tries to warm similar cache. Given we leave multiple hole in the cache that can be warmed by anyone, this is harder to avoid that we would like. We simply catch the error in this case. Someone will warm the missing entry later.

sqlcache: cache OperationError when saving This is a cache, so we should not crash when trying to operate on it. OperationError can happens when the database is seen as readonly or locked.

sqlcache: passe better connection option These new options should help with handling transaction consistency and database access on high load.

contrib: introduce a small script to stress tests obsolescence exchange Tester have been reporting some error that seems to originate from concurrent access/update to the cache. This script will be useful to reproduce these situations locally.

changelog: mention the database robutness fix in the changelog

sqlcache: also catch malformed database error This is apparently another way for sqlite to fail at concurrency.

stablerange: rework saving logic to be clearer and safer

obshashrange: rework saving branching to be clearer and safer

sqlcache: protect read query too Some error (like locked database) can even happens when doing readonly operation. So we protect them too. At that point, it seems that pysqlite3 is not the right tool for this job.

sqlite: fast path when nothing to save If we have no new data to save, we should try to do anything. Doing something concurrently is hard enough. If we can avoid doing it at all that would be great.

sqlcache: initialize meta table last It turns out that pysqlite commit after each table creation. This commit is an hopeless attemps to make the caches more concurrent friendly.

obshashrange: always check in base cachekey against the recorded one Ignoring the check in the none case is just disaster waiting to happens.

stablerangecache: fix output in the drifted case The node were not hex, and the field had different order in the pair. This is now fixed.

sqlcache: also ignore integrity error integrity error can happens when multiple client tries to warm similar cache. Given we leave multiple hole in the cache that can be warmed by anyone, this is harder to avoid that we would like. We simply catch the error in this case. Someone will warm the missing entry later.

sqlcache: cache OperationError when saving This is a cache, so we should not crash when trying to operate on it. OperationError can happens when the database is seen as readonly or locked.

sqlcache: passe better connection option These new options should help with handling transaction consistency and database access on high load.

contrib: introduce a small script to stress tests obsolescence exchange Tester have been reporting some error that seems to originate from concurrent access/update to the cache. This script will be useful to reproduce these situations locally.

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

test: adjust glob in previous changeset I forgot to glob the time.

branching: merge with stable

packaging: mark as development version This avoid confusion.

Added tag 8.1.1 for changeset e7abf863e113

packaging: prepare release 8.1.1 Topic is untouched so we keep the previous version number.

branching: merge with stable

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

changelog: add a line about improved prune documentation

changelog: reorder content

prune: more human-friendly documentation The previous help string generally had a highly technical language. I've tried my best to address that.

prune: improve help first line The previous help string for prune didn't mention successors in the first line. Note: Pierre-Yves David changed the original "hidden" to "obsolete" as it is better concept to put forward. (a bit more specific and with more consequence than just "hidden"). We need a good `hg help obsolete/obsolescence` result. We'll try to get this in the next version.

prune: try to clarify the "multi" revisions case I hope this highlight the use case for all three options.

prune: move help about biject after the one about split and fold The --biject flag seems a less common use case.

prune: no longer consider dropping --biject Field testing show it save people one wrong call often enough that it is worth keeping.

prune: more human-friendly documentation for --biject

prune: use ``-s/--succ`` in documentation Extracted by Pierre-Yves David

branching: merge with stable

compat: import the module dagutil module in evolve Discovery code is core have been rewritten to no longer depends on dagutil and the module have been removed. This break evolve's obsmarker discovery (older version of the discovery use the same concept).. A quick work around is to import the dagutil module in evolve and use that for now.

evolve: delete evolvestate after aborting interrupted `next --evolve` We didn't use to delete the evolvestate after aborting an interrupted `next --evolve`. This patch makes sure we do that. The test changes demonstrate the fix and we add a CHANGELOG entry about the fix.

tests: check that we delete evolvestate correctly after abort/stop This patch adds test to check whether we delete the evolvestate correctly after aborting or stopping an interrupted evolve which is caused because of `next --evolve`.

changelog: update with issue5927 fix

evolve: set the second parent if we get conflicts while evolving This patch makes sure we set the second parent correctly if we run into conflicts while evolving. Also, we need to make sure to reset to one parent before committing.

evolvecmd: import mercurial.node module as nodemod We use node as a variable name at few places and the conflicts with variable name are not good. Moreover this practice is followed in core mercurial also.

tests: demonstrate the interrupted evolve does not set p2 This patch adds a test to demonstrate issue5927 which is about evolving not setting p2 correctly in interruption.

cleanup: remove unused import

cleanup: remove old comment that lost all meaning

template: remove compatibility layer for `showobsolete` The keyword exist in core since 4.2

exthelper: drop compatibility layer for `command` We dropped support for 4.2.

topic: drop compat layer for `command` We dropped support for 4.2

legacy: drop compat layer for "command"

drophack: drop compat layer for "command"

compat: drop compatibility layer for updatecaches The `repo.updatecaches` method is support since Mercurial 4.2

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.