--- a/docs/sharing.rst	Sat Jun 01 02:30:14 2019 +0200
+++ b/docs/sharing.rst	Tue Jun 04 11:08:44 2019 +0200
@@ -433,7 +433,7 @@
 It's not enough just to update ``public``, though! Other people also
 use the ``review`` repository, and right now it doesn't have Bob's
 latest amendment ("v3", revision 6:540b), nor does it know that the
-precursor of that changeset ("v2", revision 5:0eb7) is obsolete. Thus,
+predecessor of that changeset ("v2", revision 5:0eb7) is obsolete. Thus,
 Bob pushes to ``review`` as well::
 
   $ hg push ../review
@@ -508,12 +508,12 @@
 but every competent chef keeps several around. Ever try to chop onions
 with a spoon?)
 
-In the user guide, we saw examples of *unstbale* changesets, which are
-the most common type of troubled changeset. (Recall that a
+In the user guide, we saw examples of *orphan* changesets, which are
+the most common type of unstable changeset. (Recall that a
 non-obsolete changeset with obsolete ancestors is an orphan.)
 
-Two other types of troubles can happen: *divergent* and
-*bumped* changesets. Both are more likely with shared mutable
+Two other types of instability can happen: *content-divergent* and
+*phase-divergent* changesets. Both are more likely with shared mutable
 history, especially mutable history shared by multiple developers.
 
 Setting up
@@ -556,11 +556,11 @@
 
 and add the same text.
 
-Example 6: Divergent changesets
-===============================
+Example 6: Content-divergent changesets
+=======================================
 
 When an obsolete changeset has two successors, those successors are
-*divergent*. One way to get into such a situation is by failing
+*content-divergent*. One way to get into such a situation is by failing
 to communicate with your teammates. Let's see how that might happen.
 
 First, we'll have Bob commit a bug fix that could still be improved::
@@ -596,11 +596,11 @@
   [...]
   added 1 changesets with 1 changes to 2 files (+1 heads)
   (run 'hg heads' to see heads, 'hg merge' to merge)
-  2 new divergent changesets
+  2 new content-divergent changesets
 
 Figure 9 shows the situation in Bob's repository.
 
-  [figure SG09: Bob's repo with 2 heads for the 2 divergent changesets, 6:a360 and 7:e3f9; wc is at 6:a360; both are successors of obsolete 4:2fe6, hence divergence]
+  [figure SG09: Bob's repo with 2 heads for the 2 content-divergent changesets, 6:a360 and 7:e3f9; wc is at 6:a360; both are successors of obsolete 4:2fe6, hence divergence]
 
 Now we need to get out of trouble. As usual, the answer is to evolve
 history. ::
@@ -619,7 +619,7 @@
 (``internal:other``) that will take Alice's changes over Bob's. (You
 might wonder why Bob wouldn't prefer his own changes by using
 ``internal:local``. He's avoiding a `bug`_ in ``evolve`` that occurs
-when evolving divergent changesets using ``internal:local``.)
+when evolving content-divergent changesets using ``internal:local``.)
 
 # XXX this link does not work
 .. _`bug`: https://bitbucket.org/marmoute/mutable-history/issue/48/
@@ -685,25 +685,25 @@
 2:e011 is now public, so it can't be obsolete. When that changeset was
 obsolete, it made perfect sense for it to have a successor, namely
 Bob's amendment of Alice's fix (changeset 4:fe88). But it's illogical
-for a public changeset to have a successor, so 4:fe88 is troubled:
-it has become *bumped*.
+for a public changeset to have a successor, so 4:fe88 is unstable:
+it has become *phase-divergent*.
 
-  [figure SG07: 2:e011 now public not obsolete, 4:fe88 now bumped]
+  [figure SG07: 2:e011 now public not obsolete, 4:fe88 now phase-divergent]
 
 As usual when there's trouble in your repository, the solution is to
 evolve it::
 
   $ hg evolve --all
 
-Figure 8 illustrates Bob's repository after evolving away the bumped
+Figure 8 illustrates Bob's repository after evolving away the phase-divergent
 changeset. Ignoring the obsolete changesets, Bob now has a nice,
 clean, simple history. His amendment of Alice's bug fix lives on, as
 changeset 5:227d—albeit with a software-generated commit message. (Bob
 should probably amend that changeset to improve the commit message.)
 But the important thing is that his repository no longer has any
-troubled changesets, thanks to ``evolve``.
+unstable changesets, thanks to ``evolve``.
 
-  [figure SG08: 5:227d is new, formerly bumped changeset 4:fe88 now hidden]
+  [figure SG08: 5:227d is new, formerly phase-divergent changeset 4:fe88 now hidden]
 
 Conclusion
 ----------
@@ -713,7 +713,7 @@
 dull knife (never mind a rusty spoon). At the same time, an
 inattentive or careless user can do harm to himself or others.
 Mercurial with ``evolve`` goes to great lengths to limit the harm you
-can do by trying to handle all possible types of “troubled”
+can do by trying to handle all possible types of “unstable”
 changesets. Nevertheless, having a first-aid kit nearby does not mean
 you should stop being careful with sharp knives.