/!\ This page is primarily intended for Mercurial's developers.

Changesets Evolution - Development Roadmap.

This is the current Roadmap for the ChangesetEvolution concept. See ChangesetEvolutionDevel for more details.

Current status:

1. Stage A

Changeset Evolution is currently at Alpha Stage. If won't eat people data, but only handful of people knowns how to get out some situation.

This stage involves:

2. Stage B

We are currently working on achieving this state.

All the "core" features should be here and somewhat work. Some will be sluggish and unpleasant to use as the focus is not yet on user interface.

We can gather the base-line expectations for this stage in 4 groups.

2.1. Displaying Evolution History to the User

Now that we (almost) have all the brick to build a clean evolution history, there is a lot of way we could easily expose it to the user. This is critical to ensure the user have some awareness of the feature and is able to understand what is happening in case of troubles.

2.2. Troubles Resolution

Users need to know that he can trust the tool to offer him what it needs and bring him out of trouble. We have already cover a good share of that work with a descent hg evolve command handle most common case and a large set of small commands to each operation. Yet there is some area where the user is still left with no "simple" option.

2.3. Troubles Prevention

There is multiple cases were we know that an action from the user will create troubles (most notably divergence) preventing the user to do so in the first place (in the same philosophy) as phase would be very useful,

2.4. Low level Utilities

Currently, the "obsstore" is not really "fixable" having tool available to very advanced users would be good.

3. Stage C

At this "beta" state, the UI and experience will not be easy/pleasant enough for normal user, but advance user of Mercurial should find their mark. We may consider shipping it with Core Mercurial with an experimental flag.

Blocker to beta release:

4. Release Stage

A which point we can merge changesets evolution into core.

5. Notable UI changes planned by final release

This is a tentative list, some item might changes or be dropped, other might be added. The goal is to give a better idea of the current targets even if some are still vague lead.

(more concrete example should be added to each item over time)

5.1. Better inspection of the obsolescence data

We wants better ability to looks at the obsolescence graph:

In addition there are interesting UI option around showing a group of changeset in the way they will be once evolved. See the #grouping_changesets_and_stack_workflow section or PlanHistoryRewritePlan.

We have multiples options to help user tracks what happens to their repositories

5.3. preventing creation of instability (formerly troubles)

As pointed in CEDConcept it is easier to prevent bad situation than fixing them.

Plan to reduce chances of 'instability' are as follow

5.4. grouping changesets and stack workflow

Something related to FeatureBranchesStruggle can help to smooth many of the evolution rough edges. If we can group changeset by "feature" is helps with the following area

* The scope of hg evolve --all will be simpler to define,

* we can have associated command that display a limited number of changeset in a "linearized" way (as if evolve was applied),

* clear flagging of in progress feature can helps with the pushblishing workflow.

The TopicPlan provide some good lead for this.

6. Evolve Extension: Content and Status

Summary of the Evolve extensions content and status (the standard process is for things to mature in the evolve extensions and get quick user feedback, then moved into core).



Code Quality

Obsmarkers Discovery

(./) Approach validated, ready to upstream

Code and data structure are prototypes stage

Rewriting Command

{i} Mostly there, some UI question

Code quality is good overall

Bringing back obsolete changeset

<!> Rewind command under development

in progress

UI Message

<!> Partially upstreamed, need more details for push/pull

Code quality: hacky

Troubles Prevention

{X} pre-check and ownership needs more work

in progress

Troubles Handling (evolve)

{X} More comprehensive handling of instability needed (getting there)

Code quality is okay overall

Access to obsolescence history

(./) Already Partially upstreamed, rest ready to move

Code quality: hacky


(./) Approach validated, ready to upstream

Code is hacky until moved to core

CategoryDeveloper CategoryEvolution

CEDRoadMap (last edited 2018-03-04 20:54:00 by BorisFeld)