Changesets Evolution - Development Roadmap.

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

Current status:

• Alpha Stage,

• Stage B (in-progress),

• Stage C

• Release Stage,

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:

• changesets can be hidden using obsolescence markers,
• obs-markers are created by all history rewriting operations,
• obs-markers can be exchanged between repositories,
• all evolution "troubles" arising from the exchange and rewrite of draft changesets are detected,
• user is warned when this happens,

• the most common and simple case of troubles can be automatically resolved through the hg evolve commands,

• user is provided a set of commands to handle basic rewriting operations (hg amend, hg split, hg fold, etc…)

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.

• displaying the meta history: users should have access to the obsolescence information recorded by Mercurial,

• troubles resolutions: all users should be confident it will get out of "troubles" by itself,
• troubles prevention: the best way to solve a trouble is to not have it in the first place,

• low level utility: advanced users should be able to fix their repository by themselves if things go wrong.

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.

• Having "hg evolve --list" displaying troubled changesets, troubles affecting

  • them and details of the diagnostic

• Basic display of precursors/successors available in hg log

• Some highlight of obsolete/unstable node in default log (color?)

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.

• Evolve should have predictable result (--rev options and co),

• Evolve should be able to somewhat handle all possible troubles (including
  • divergence and bumping)
• Evolve should have a working --abort and --continue (and --drop?)
• We must have some command to "bring obsolete changeset" back. (issue4851)

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,

• Having rebase skip changesets with successors in destination,

• Having a generic mechanism to run "validation" before any "editing" of a

  • changeset,
• requires a special flag or config to create divergence locally.

2.4. Low level Utilities

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

• Some debug command to strip arbitrary markers?

• "hg strip" should have a way to strip related obsolescence markers,

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:

• Obsmarkers exchange should be good enough to define a final storage format for markers.
• On disk format should be stable in the foreseeable future and fit performance/exchange need. (avoid needs for data migration)

• Support solving instability corner cases in hg evolve

• Performance impact should be reasonable,

• Seeing past operation and "rewinding" them should be a thing.

4. Release Stage

At which point we can merge changesets evolution into core.

• UI offering a Solution to the N² markers creation when editing history (TopicPlan),

• Commands set defined enough to be freezed for backward compatibility

• No race condition when exchanging with server (bundle2 + repo layout allowing atomic transaction),

• No impactful Performance Regression (including efficient exchange),
• Concrete plan to handle high volume of markers (archiving or something),

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:

• There are plan for more obsolescence related information in hg log (e.g.: displaying successors/precursors when they are also visible, similar to what tortoise-hg is doing).

• Stronger "obsolescence log" feature to display what changes happened to a changeset (when, who, what, diff, etc)

• Recording the "type" of operation in obsmarkers (content change, rebase, message change, metadata changesets, etc). That data will be used in the two items above.

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.

5.2. better report on obsolescence related changes

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

• improved output to hg pull

• easy access to past obsolescence (probably through the hg journal command)

• extra focus put on obsolescence applied to changeset owned by the user. (more on "owning" in the next section)

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

• unified checking function before any rewrites: this will helps preventing user from creating various unstable states (priority target divergence)

• introduce some concept of "owning changeset". By default, user would be allowed to rewrite their changesets only (low impact BC in a non publishing world) and can opt-in to rewrite changesets from more users. see CEDPrecheckPlan for details

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).

CategoryDeveloper CategoryEvolution