Mercurial > hg
comparison mercurial/helptext/evolution.txt @ 47017:da4e6d7a8fdd
help: add topic about evolution, based on text from evolve extension
I've taken the text produced by `hg help evolution` when the evolve
extension is enabled and made that available by the same command with
just hg core. Changes I've made:
* Added "(EXPERIMENTAL)" to the title. (That doesn't hide the topic
from `hg help`, though.)
* Replaced old-style `experimental.evolution=<names>` config by
new-style `experimental.evolution.<name>=true`.
* Replaces a "obsolete markers" by "obsolescence markers".
* Removed most content from "Current feature status".
When the evolve extension is enabled, its help text takes precedence.
Differential Revision: https://phab.mercurial-scm.org/D10516
author | Martin von Zweigbergk <martinvonz@google.com> |
---|---|
date | Tue, 27 Apr 2021 14:59:45 -0700 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
47016:8ad2f43fe37b | 47017:da4e6d7a8fdd |
---|---|
1 Obsolescence markers make it possible to mark changesets that have been | |
2 deleted or superseded in a new version of the changeset. | |
3 | |
4 Unlike the previous way of handling such changes, by stripping the old | |
5 changesets from the repository, obsolescence markers can be propagated | |
6 between repositories. This allows for a safe and simple way of exchanging | |
7 mutable history and altering it after the fact. Changeset phases are | |
8 respected, such that only draft and secret changesets can be altered (see | |
9 :hg:`help phases` for details). | |
10 | |
11 Obsolescence is tracked using "obsolescence markers", a piece of metadata | |
12 tracking which changesets have been made obsolete, potential successors for | |
13 a given changeset, the moment the changeset was marked as obsolete, and the | |
14 user who performed the rewriting operation. The markers are stored | |
15 separately from standard changeset data can be exchanged without any of the | |
16 precursor changesets, preventing unnecessary exchange of obsolescence data. | |
17 | |
18 The complete set of obsolescence markers describes a history of changeset | |
19 modifications that is orthogonal to the repository history of file | |
20 modifications. This changeset history allows for detection and automatic | |
21 resolution of edge cases arising from multiple users rewriting the same part | |
22 of history concurrently. | |
23 | |
24 Current feature status | |
25 ====================== | |
26 | |
27 This feature is still in development. | |
28 | |
29 Instability | |
30 =========== | |
31 | |
32 Rewriting changesets might introduce instability. | |
33 | |
34 There are two main kinds of instability: orphaning and diverging. | |
35 | |
36 Orphans are changesets left behind when their ancestors are rewritten. | |
37 Divergence has two variants: | |
38 | |
39 * Content-divergence occurs when independent rewrites of the same changesets | |
40 lead to different results. | |
41 | |
42 * Phase-divergence occurs when the old (obsolete) version of a changeset | |
43 becomes public. | |
44 | |
45 It is possible to prevent local creation of orphans by using the following config:: | |
46 | |
47 [experimental] | |
48 evolution.createmarkers = true | |
49 evolution.exchange = true | |
50 | |
51 You can also enable that option explicitly:: | |
52 | |
53 [experimental] | |
54 evolution.createmarkers = true | |
55 evolution.exchange = true | |
56 evolution.allowunstable = true |