note on bookmarks.
diff --git a/workflow.txt b/workflow.txt
--- a/workflow.txt
+++ b/workflow.txt
@@ -28,7 +28,7 @@ A complete Mercurial branching strategy
[^graft]: If you want to release the changes from `default` in smaller chunks, you can also graft specific changes into a release preparation branch and merge that instead of directly merging default into stable. This can be useful to get real-life testing of the distinct parts. For details see the extension [Graft changes into micro-releases](#graft-releases).
[^bookmarks]: This model does not use bookmarks, because they don’t offer benefits which outweight the cost of introducing another concept, and because named branches for feature branches offer the advantage, that new programmers never get the code from a feature-branch when they clone the repository. For local work and small features, bookmarks can be used quite well, though, and since this model does not define their use, it also does not limit it.
-Additionally bookmarks could be useful for feature branches, if you use many of them (in that case reusing names is a real danger and not just a rare annoyance) or if you use release branches:
+Additionally bookmarks could be useful for feature branches, if you use many of them (in that case reusing names is a real danger and not just a rare annoyance, and if you have a recent Mercurial, you can use the `@` bookmark to signify the entry point for new clones) or if you use release branches:
“What are people working on right now?” → `hg bookmarks`
“Which lines of development do we have in the project?” → `hg branches`
@@ -408,7 +408,7 @@ Commands:
### Feature branches
-*Now we want to do some larger development, so we use a feature branch. The one feature-commit shown here (x) could be an arbitrary number of commits, and as long as you stay in your branch, the development of your colleagues will not disturb your own work. Once the feature is finished, we merge it into default. That gives us changesets 9 to 11. Changeset 10 is a commit added in-between on the default branch.*
+*Now we want to do some larger development, so we use a feature branch. The one feature-commit shown here (x) could be an arbitrary number of commits, and as long as you stay in your branch, the development of your colleagues will not disturb your own work. Once the feature is finished, we merge it into default. That gives us changesets 12 to 16.*
o changeset: 16:2088b93fb3f4
|\ parent: 14:684c6176ce71
@@ -482,6 +482,8 @@ Commands:
*Note: To make the final merge of your feature into default easier, you can regularly merge the default branch into the feature branch.*
+*Note: We use feature branches to ensure that new clones start at a revision which other developers can directly use. With bookmarks you could get trapped on a feature-head which might not be merged to `default` for quite some time. For more reasons, see the relevant [footnote](#fn:bookmarks).*
+
The final action is a regular release. Since we already showed that, we are finished here.
<a name="extensions"></a>