354 ``evolve`` apart from other history modification mechanisms is the

   354 ``evolve`` apart from other history modification mechanisms is the

   355 fact that it recognizes instability like orphan changesets and provides

   355 fact that it recognizes instability like orphan changesets and provides

   356 a consistent way for you to get back to a stable repository.

   356 a consistent way for you to get back to a stable repository.

   357 

   357 

   358 (Incidentally, there are two other types of instability that changesets

   358 (Incidentally, there are two other types of instability that changesets

   360 *bumped*. Both of those states are more likely to occur when

   360 *bumped*. Both of those states are more likely to occur when

   361 `sharing mutable history`_, so we won't cover them in this user guide.)

   361 `sharing mutable history`_, so we won't cover them in this user guide.)

   362 

   362 

   363 .. _`sharing mutable history`: sharing.html

   363 .. _`sharing mutable history`: sharing.html

   364 

   364 

   592 

   592 

   593 The current implementation of ``hg touch`` is not ideal, and is likely to

   593 The current implementation of ``hg touch`` is not ideal, and is likely to

   594 change in the future. Consider the history in Figure 12, where revision 27

   594 change in the future. Consider the history in Figure 12, where revision 27

   595 is obsolete and the child of 26, also obsolete. If we ``hg touch 27``, that

   595 is obsolete and the child of 26, also obsolete. If we ``hg touch 27``, that

   596 creates a new revision which is a non-obsolete child of 26—i.e., it is an

   596 creates a new revision which is a non-obsolete child of 26—i.e., it is an

   598 about in the `next section`_.

   598 about in the `next section`_.

   599 

   599 

   600 .. _`next section`: sharing.html

   600 .. _`next section`: sharing.html