|
Size: 1138
Comment: Very basic first draft about the evolution concept
|
Size: 5366
Comment: add link to the video
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 2: | Line 2: |
| = Changeset Evolution Plan = /!\ This page is intended for developers |
|
| Line 5: | Line 3: |
| Proposition for safe rewriting of mercurial history. This will have a close relationship with StatesPlan | = Changesets Evolution = <<TableOfContents>> Changeset Evolution is a set of features to gracefully handle history rewriting operations. It offers a '''safe''' and '''simple''' way to refine changesets. Results of your local history rewriting operations can be propagated to other clones in a '''solid''' way. It is even possible for multiple people to rewrite the same part of the history in a distributed way. You can watch the [[explanation of the concept at fosdem 2013|https://air.mozilla.org/changesets-evolution-with-mercurial/]] to learn more. |
| Line 8: | Line 14: |
| == Core principle == | /!\ '''The changeset evolution concept is still being implemented. And disabled by default.''' |
| Line 10: | Line 16: |
| * Store and explicit relation between new and old version of rewritten changeset. | The functionality is currently available with and external extension: EvolveExtension. |
| Line 12: | Line 18: |
| * This relation should *not* be part of the changeset (should not alter the hash). * People must be able to collaborate on evolving changeset |
/!\ '''Using this EvolveExtension will alter some of the core commands and behaviors.''' |
| Line 17: | Line 21: |
| == Additional idea == | |
| Line 19: | Line 22: |
| * Save delta in a real changeset. | |
| Line 21: | Line 23: |
| * This relation should be exchangeable without rewritten changeset. | == Rewriting history == |
| Line 23: | Line 25: |
| * Easily allow other extension to manipulate such relation (and to hook on such operation) | Mercurial offers multiple commands to rewrite history: |
| Line 25: | Line 27: |
| == Situation that should be handled == | * `hg commit --amend`: can add more changes into a commit * `hg rebase`: can move changesets around in your graph (requires the RebaseExtension) * `hg histedit`: can perform rewrite operation on some of your changesets (requires the HisteditExtension) |
| Line 27: | Line 31: |
| * Rewriting content of a changeset, | The experimental EvolveExtension adds more commands, which will eventually moved into core: |
| Line 29: | Line 33: |
| * delete/kill a changeset. | * `hg uncommit`: can remove changes from a commit and put them back in your working directory * `hg fold`: can squash multiple changesets together as a single new commit * `hg prune`: can remove changesets from your history |
| Line 31: | Line 37: |
| * split a single changeset in multiple one, | All these operations are '''very safe to use''', even for Mercurial rookies. Mercurial will actively prevent you to rewrite part of the history which are not safe to rewrite. Read about the [[Phases]] concept for details. |
| Line 33: | Line 41: |
| * collapse multiple changeset in single one, | == Tracking and sharing rewriting == |
| Line 35: | Line 43: |
| * change changeset order, | Obsolescence markers make it possible to mark changesets that have been deleted or superseded in a new version of the changeset. |
| Line 37: | Line 46: |
| * adding (eg pulling) a changeset evolution that conflict with another one. | Unlike the previous way of handling such changes (which stripped the old changesets from the repository), obsolescence markers can be propagated between repositories. This allows for a safe and simple way of exchanging mutable history and altering it after the fact. Changeset phases are respected, such that only drafts and secret changesets can be altered (see `hg phases` for details). |
| Line 39: | Line 52: |
| * adding (or adding in general ) new changesets on a one which already evolved (or evolving a changeset that have descendant) | Obsolescence is tracked using "obsolescence markers", a piece of metadata that tracks which changesets have been made obsolete, potential successors for a given changeset, the moment the changeset was marked as obsolete, and the user who performed the rewriting operation. The markers are stored separately from standard changeset data and can be exchanged without any of the precursor changesets, preventing unnecessary exchange of obsolescence data. The complete set of obsolescence markers describes a history of changeset modifications that is orthogonal to the repository history of file modifications. This changeset history allows for detection and automatic resolution of edge cases arising from multiple users rewriting the same part of history concurrently. == Automatic detection and resolution arising troubles == Exchanging mutable changesets has inherent ''troubles'' that we must be prepare to deal with. Most people will never run into them but Mercurial is able to detect and solve them automatically. There are three kinds of '''troubled changesets''' In some situations you may have non-obsolete changesets descending from obsolete changesets. Such changesets are said to be "unstable". In some other situations you may have successors for changesets which are now [[immutable||Phases]]. In such case the obsolescence marker does not apply and the unlucky successors are said to be "bumped". Finally when multiple changesets claim to be the successors of changesets they are said to be "divergent". When Mercurial detect such ''troubles'' it will warn the user and prevent push by default. You can use the `hg evolve` command to automatically resolve them. This command is partially implemented in the EvolveExtension. == Current implementation state (Mercurial 2.5.1) == Most history rewritting commands can now create obsolescence markers instead of stripping: * `commit --amend` * `rebase` * `histedit` This behavior is disabled by default. You need to explicitly enable obsolescence support using EvolveExtension to get this behavior. When using obsolescence markers, those commands are allowed to rewrite an arbitrary part of the history leaving untouched descendant behind as unstable. `log --graph` will use 'x' instead of 'o' to display obsolete changesets. Obsolete changesets with no non-obsolete descendants are said to be "extinct" and are hidden to all mercurial commands and changesets exchanged. A `--hidden` switch is added globally to have them accessible again. Obsolescence markers will be exchanged between repositories that explicitly assert support for the obsolescence feature (this can currently only be done via an extension). Successors of a changeset are seen as valid destinations for bookmarks. == Older materials == * Initial presentation at Copenhagen: http://public.octopoid.net/talk.pdf * First tutorial, written by Peter Arrenbrecht: http://arrenbrecht.ch/mercurial/evolution/ |
Changesets Evolution
Contents
Changeset Evolution is a set of features to gracefully handle history rewriting operations. It offers a safe and simple way to refine changesets. Results of your local history rewriting operations can be propagated to other clones in a solid way. It is even possible for multiple people to rewrite the same part of the history in a distributed way. You can watch the https://air.mozilla.org/changesets-evolution-with-mercurial/ to learn more.
![/!\](/moin-static/modernized/img/alert.png "/!\"){kind=small}
The changeset evolution concept is still being implemented. And disabled by default.
The functionality is currently available with and external extension: EvolveExtension.
Using this EvolveExtension will alter some of the core commands and behaviors.
1. Rewriting history
Mercurial offers multiple commands to rewrite history:
hg commit --amend: can add more changes into a commit
hg rebase: can move changesets around in your graph (requires the RebaseExtension)
hg histedit: can perform rewrite operation on some of your changesets (requires the HisteditExtension)
The experimental EvolveExtension adds more commands, which will eventually moved into core:
hg uncommit: can remove changes from a commit and put them back in your working directory
hg fold: can squash multiple changesets together as a single new commit
hg prune: can remove changesets from your history
All these operations are very safe to use, even for Mercurial rookies. Mercurial will actively prevent you to rewrite part of the history which are not safe to rewrite. Read about the Phases concept for details.
2. Tracking and sharing rewriting
Obsolescence markers make it possible to mark changesets that have been deleted or superseded in a new version of the changeset.
Unlike the previous way of handling such changes (which stripped the old changesets from the repository), obsolescence markers can be propagated between repositories. This allows for a safe and simple way of exchanging mutable history and altering it after the fact. Changeset phases are respected, such that only drafts and secret changesets can be altered (see hg phases for details).
Obsolescence is tracked using "obsolescence markers", a piece of metadata that tracks which changesets have been made obsolete, potential successors for a given changeset, the moment the changeset was marked as obsolete, and the user who performed the rewriting operation. The markers are stored separately from standard changeset data and can be exchanged without any of the precursor changesets, preventing unnecessary exchange of obsolescence data.
The complete set of obsolescence markers describes a history of changeset modifications that is orthogonal to the repository history of file modifications. This changeset history allows for detection and automatic resolution of edge cases arising from multiple users rewriting the same part of history concurrently.
3. Automatic detection and resolution arising troubles
Exchanging mutable changesets has inherent troubles that we must be prepare to deal with. Most people will never run into them but Mercurial is able to detect and solve them automatically.
There are three kinds of troubled changesets
In some situations you may have non-obsolete changesets descending from obsolete changesets. Such changesets are said to be "unstable".
In some other situations you may have successors for changesets which are now immutable. In such case the obsolescence marker does not apply and the unlucky successors are said to be "bumped".
Finally when multiple changesets claim to be the successors of changesets they are said to be "divergent".
When Mercurial detect such troubles it will warn the user and prevent push by default. You can use the hg evolve command to automatically resolve them.
This command is partially implemented in the EvolveExtension.
4. Current implementation state (Mercurial 2.5.1)
Most history rewritting commands can now create obsolescence markers instead of stripping:
commit --amend
rebase
histedit
This behavior is disabled by default. You need to explicitly enable obsolescence support using EvolveExtension to get this behavior. When using obsolescence markers, those commands are allowed to rewrite an arbitrary part of the history leaving untouched descendant behind as unstable.
log --graph will use 'x' instead of 'o' to display obsolete changesets.
Obsolete changesets with no non-obsolete descendants are said to be "extinct" and are hidden to all mercurial commands and changesets exchanged. A --hidden switch is added globally to have them accessible again.
Obsolescence markers will be exchanged between repositories that explicitly assert support for the obsolescence feature (this can currently only be done via an extension).
Successors of a changeset are seen as valid destinations for bookmarks.
5. Older materials
Initial presentation at Copenhagen: http://public.octopoid.net/talk.pdf
First tutorial, written by Peter Arrenbrecht: http://arrenbrecht.ch/mercurial/evolution/