Changesets Evolution - development page.

/!\ This page is intended for developer

{i} For a user perspective see ChangesetEvolution.

1. Contributing

The simplest way to help is to grab one of: list of easy bug

There is also a multiple well defined topic that where idea exist but needs an implementation

There is more complicated part that requires attention too.

2. Roadmap

See CEDRoadMap

3. Overall concept

See CEDConcept

Other concept not directly involved in Changeset Evolution and closely related for technical or user experience reason.

5. In progress Features and discussion

5.1. Using Obsolescence Marker during Rebase

There is two big issues with rebasing a set containing obsolescence changeset:

To enable the current implementation set the config experimental.rebaseskipobsolete to true.

Current progress:

5.2. `hg evolve --list`

This is also tracked in https://bz.mercurial-scm.org/show_bug.cgi?id=4845

Evolution can compute a lot of information out of the obsolescence graph. It already use it to compute troubles and automatically solve them. Yet this information is not easily accessible to the user.

We would like to gain a basic version of hg evolve --list that would provide all available information on current troubles.

5.2.1. Output Proposal

More concrete example:

5633576f2df1: unbundle: cleanly abort on unknown ...

We want to ensure this is implemented through the 'formatter' API so we gain structured output easily "eg -Tjson"

5.2.2. Command Line API

We probably want

5.2.3. Details on Each Trouble Cases

Here is some idea for data we could provide in each cases. This provide an handy list of case in the process.

5.2.3.1. Unstable from Obsolete Parent

5.2.3.2. Unstable from Unstable Parent

5.2.3.3. Unstable Merge

5.2.3.4. Bumped Changeset

5.2.3.5. Divergent Changeset

5.2.3.6. Divergent with the other side public

This is actually one of the most common divergence scenario. We probably need a dedicated name for this.

5.2.3.7. Visible Obsolete Changeset

Should list them with a mention of why they are still visible?

5.3. obsmarker support in `hg strip`

We would like to be able to strip obsolescence marker related to a changeset when stripping it.

We want:

The "obsmarker in the backup bundle" will requires some work because there is no other place storing obsmarkers in an on disk bundle. However, all infra should be in place as we already exchange obsmarker over the wire through a bundle.

In the same go, you can consider adding obsmarker support to hg bundle through the "variants" part of the type.

5.4. `hg evolve --continue/--abort/--drop`

Currently evolve implement a super basic state format that does not allow a proper "multi step" behavior.

5.4.1. About `--continue`

Current issues

We need to update the format on disk to allow these.

5.4.2. About `--abort`

This does not exists but it would be useful.

5.4.3. About `--drop`

Currently, user can "abandon" his evolve at any time. leaving half of the thing evolved and the other one still unstable. That is a pretty cool feature we want a way to keep. Adding a flag could be a way. openning the way to similar feature in other multi step command.

Name is not frozen, this is the first time we mention it.

Maybe we just want hg up -C to be that, but it seems a bit too easy to run by mistake.

5.5. Tagging draft changeset

Currently tagging draft a changeset may lead to issues when the tagged changeset is rewritten and its hash change, making the tag invalid.

Here is a small (draftish) list of ideas to handle the question, the first one "rewriting the tag file when we evolve/rewrite the tagging changeset" is probably the way to go.

Mailing list discussion about this: https://www.mercurial-scm.org/pipermail/evolve-testers/2016-May/000178.html

5.5.1. rewriting the tag file when we evolve/rewrite the tagging changeset

When the tagging changeset is evolved (changed from a descendant of the old tagged, to the new version), we could rewrite the content of the tag file.

Pro:

Cons:

5.5.2. Warn when pushing a draft tag

The idea is that pushing a tagged changeset as draft increase the risk of rewrite, so warning could help having user think about turning them public.

Pro:

Cons:

5.5.3. Warn when rewriting a draft tag

Pro:

Cons:

5.5.4. Turning the changeset public on tagging

Pro:

Cons:

5.5.5. Turn the tagged changesets public on push

Pro:

Cons:

5.5.6. refuse to tag draft

Pro:

Cons:

5.6. Obsolescence Marker Discovery

5.7. amend/uncommit/recommit/etc

A recurring discussion is "What should be 'base' for the 'amend' operation" (or other related command).

The complexity of the situation comes from the fact we have 3 states of interest

  1. wc(): The working copy content (on disk file)

  2. p1(): The working copy parent content (commit content, affected by commands)

  3. p1()~1: The working copy parent (commit content).

Various core command already allow to interact with these layers.

* The commit command move content from wc() to p1() (creating a new p1()) in the process), * The commit --amend is just a variation of that moving content from wc() to p1() (reusing the existing one). * The revert command move content from p1() to wc() * The revert --rev command move content from any commit content to wc()

Evolve have various commands in this area too.

* The amend command mimic commit --amend, moving content from wc() to p1() * The uncommit command move content from p1()~1 to p1().

A common question is to change the default of amend to use p1()~1 as base. Picking change from wc() when selected and resetting to p1()~1 for excluded content. "Just changing the default" is not a solution here. We have multiple possibilities (because we have 3 states to select from) and if we change from one to the other, some people will just start asking for the other one instead.CategoryNewFeatures

However, having an easy way to select the mode would be nice, gather all usecase into a single command would be preferable. Building a good UI for that might allow us to remove the dedicated uncommit command and provide a recommit capabilities that people have been asking for.

5.8. Record types of operation

Storing more information about what the type of rewrite in obsolescence markers would be useful. The idea is to leverage the bitfield in the markers to record various kind of actions.

5.8.1. Recorded actions

And probably these extra data too:

The various edition command will be responsible for adding useful information:

5.8.2. Advantages

5.8.3. Usage

Having that data will help providing information about the obsolescence history. Example:

     @  ac28e3  durham
    /   First commit
   |
   | o  d4afe7 durham
   | |  Second commit
   | |
   | x  8e9a5d (Amended as ac28e3)  durham
   |/   First commit
   |

6. See Also


CategoryNewFeatures CategoryDeveloper CategoryEvolution

ChangesetEvolutionDevel (last edited 2017-05-10 10:03:02 by Pierre-YvesDavid)