Note:

This page is primarily intended for developers of Mercurial.

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. It won't eat people's data, but only handful of people know how to get out of some situations.

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 are a lot of ways we could easily expose it to the user. This is critical to ensure the user has 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 covered a good share of that work with a descent hg evolve command that handles most common cases and a large set of small commands to each operation. Yet there are some areas where the user is still left with no "simple" option.

2.3. Troubles Prevention

There are multiple cases where we know that an action from the user will create troubles (most notably divergence). Preventing the user from doing 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 advanced 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

At which point we can merge changesets evolution into core.

5. Notable UI changes planned by final release

This is a tentative list. Some items might change or be dropped; others 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 want better ability to look at the obsolescence graph:

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

We have multiple options to help user track what happens to their repositories

5.3. preventing creation of instability (formerly troubles)

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

Plans 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" this helps with the following areas

* 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 publishing workflow.

The TopicPlan provide some good lead for this.

6. Evolve Extension: Content and Status

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

Topic

Status

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

Stack/Topic

(./) Approach validated, ready to upstream

Code is hacky until moved to core


CategoryDeveloper CategoryEvolution

CEDRoadMap (last edited 2019-11-30 07:03:49 by aayjaychan)