#
#
# rename "wiki/CommitEarlyCommitOften.moin"
#     to "wiki/CommitEarlyCommitOften.mdwn"
# 
# patch "wiki/AutomateMagic.mdwn"
#  from [d13b637a0a5160209852bd3106d57962a58e853c]
#    to [8bacd55f8c37393878b6bc15626497cf3cb763cf]
# 
# patch "wiki/BestPractices.mdwn"
#  from [444152808caabf5e5d1394e6881d9680fd905c03]
#    to [92a3b78ecc51e17af446205f370c26f03805faac]
# 
# patch "wiki/CommitEarlyCommitOften.mdwn"
#  from [2a5ce9d87b63b604915bf2f6d8ed5cdaf364ff9a]
#    to [dd4a09be8702453af2c2b017639555610ead03b7]
#
============================================================
--- wiki/AutomateMagic.mdwn	d13b637a0a5160209852bd3106d57962a58e853c
+++ wiki/AutomateMagic.mdwn	8bacd55f8c37393878b6bc15626497cf3cb763cf
@@ -1,4 +1,4 @@
-[[!tag migration-auto]]
+[[!tag migration-done]]
 
 ### Show log entries for a given SELECTOR
 
============================================================
--- wiki/BestPractices.mdwn	444152808caabf5e5d1394e6881d9680fd905c03
+++ wiki/BestPractices.mdwn	92a3b78ecc51e17af446205f370c26f03805faac
@@ -1,16 +1,18 @@
-[[!tag migration-auto]]
+[[!tag migration-done]]
 
 There is more than one one way to get things done with monotone. Listed here is guidance in best practices in using monotone. Following these procedures will help you get the most out of monotone, and help avoid common pitfalls. 
 
+[[!table header=no data="""
+[[CommitEarlyCommitOften]]      | Making smaller changes makes it easier for others to pluck them
+[[DaggyFixes]]                  | Use the ancestry graph to save fix backporting and release management work
+[[ZipperMerge]]                 | Use the ancestry graph to save branch integration and merging work
+[[BranchNamingConventions]]     | Name branches consistently
+[[CreatingBranches]]            | Best way to create branches
+[[VendorBranchPattern]]         | How to integrate other people's code into your project
+[[BranchAssemblyPattern]]       | Partition modules into branches, and assemble project with `merge_into_dir`
+[[DevelopmentBranchPattern]]    | Develop features on branches, and then merge
+[[ReleaseBranchPattern]]        | How to deliver a project to other people
+[[DifferentDbsForServeAndWork]] | Keeping your work database and the monotone server's database separate
+[[OneBranchPerDbForServe]]      | Don't keep all of your eggs in one basket
+[[RunDbCheckOften]]             | Catch database corruption early
+"""]]
-||CommitEarlyCommitOften      || Making smaller changes makes it easier for others to pluck them ||
-||DaggyFixes                  || Use the ancestry graph to save fix backporting and release management work ||
-||ZipperMerge                 || Use the ancestry graph to save branch integration and merging work ||
-||BranchNamingConventions     || Name branches consistently ||
-||CreatingBranches            || Best way to create branches ||
-||VendorBranchPattern         || How to integrate other people's code into your project ||
-||BranchAssemblyPattern       || Partition modules into branches, and assemble project with `merge_into_dir` ||
-||DevelopmentBranchPattern    || Develop features on branches, and then merge ||
-||ReleaseBranchPattern        || How to deliver a project to other people ||
-||DifferentDbsForServeAndWork || Keeping your work database and the monotone server's database separate ||
-||OneBranchPerDbForServe      || Don't keep all of your eggs in one basket ||
-||RunDbCheckOften             || Catch database corruption early ||
============================================================
--- wiki/CommitEarlyCommitOften.moin	2a5ce9d87b63b604915bf2f6d8ed5cdaf364ff9a
+++ wiki/CommitEarlyCommitOften.mdwn	dd4a09be8702453af2c2b017639555610ead03b7
@@ -1,12 +1,14 @@
+[[!tag migration-wip]]
+
 Don't group many changes together into a single commit. Commit each logical change as a separate revision.
 
 Keeping changes small and simple in individual commits makes many later things easier:
 
  * small, atomic changes are easier to `disapprove` later. 
- * This makes it easier for others using `pluck` for CherryPicking only the changes they are interested in, because each can be referred to separately.  
- * If you separate bug fix commits from other development, it will help release management (especially if you commit them according to the DaggyFixes pattern). 
- * Doing frequent commits along a separate development line will also help when it comes time later to merge that development back with other work (as well as helping you go back to a previous state if some experimental changes didn't work out well).  If you haven't done progressive propagates to keep the development branch in sync with the mainline during development, you can use the ZipperMerge pattern to recreate these small merges later.
+ * This makes it easier for others using `pluck` for [[CherryPicking]] only the changes they are interested in, because each can be referred to separately.  
+ * If you separate bug fix commits from other development, it will help release management (especially if you commit them according to the [[DaggyFixes]] pattern). 
+ * Doing frequent commits along a separate development line will also help when it comes time later to merge that development back with other work (as well as helping you go back to a previous state if some experimental changes didn't work out well).  If you haven't done progressive propagates to keep the development branch in sync with the mainline during development, you can use the [[ZipperMerge]] pattern to recreate these small merges later.
 
 If you find yourself making several parallel changes, consider using parallel workspaces, one for each change. 
 
+Using restrictions on the `commit` command (ie. `mtn commit file_a file_b`) to commit a small subset of the changes in your workspace. Check with `diff` to review what changes the restriction matches.
-Using restrictions on the `commit` command (ie. mtn commit file_a file_b) to commit a small subset of the changes in your workspace. Check with `diff` to review what changes the restriction matches.