README.rdoc in graph_mediator-0.2.1 vs README.rdoc in graph_mediator-0.2.2

@@ -29,18 +29,18 @@
   save.
 * :cacheing - any calculations which rely on the state of a reconciled graph
   but which do not themselves alter the graph (in that they are reproducible
   from existing state) should be made in the cacheing phase.
 * :bumping - if the class has a +lock_column+ set
-  (ActiveRecord::Locking::Optimistic) and has on +updated_at/on+ timestamp then
+  (ActiveRecord::Locking::Optimistic) and has on <b>updated_at/on</b> timestamp then
   the instance will be touched, bumping the +lock_column+ and checking for stale
   data.
 
 During a mediated_transaction, the +lock_column+ will only update during the 
 +bumping+ phase of the after_mediation callback.
 
-But if there is no +update_at/on+ timestamp, then +lock_column+ cannot be
+But if there is no <b>update_at/on</b> timestamp, then +lock_column+ cannot be
 incremented when dependent objects are updated.  This is because there is 
 nothing to touch on the root record to trigger the +lock_column+ update.
 
 GraphMediator ensures that after_mediation is run only once within the context
 of a mediated transaction.  If the block being mediated returns false, the
@@ -88,23 +88,24 @@
 == Caveats
 
 A lock_column and timestamp are not required, but without both columns in your schema
 there will be no versioning.
 
-+A lock_column by itself *without* a timestamp will not increment and will not provide
-any optimistic locking in a class including GraphMediator!+
+<em>A lock_column by itself *without* a timestamp will not increment and will not provide
+any optimistic locking in a class including GraphMediator!</em>
 
-Using a lock_column along with a counter_cache in a dependent child will raise a StaleObject
-error during a mediated_transaction if you touch the dependent.
+Using a lock_column along with a counter_cache in a dependent child will raise
+a StaleObject error during a mediated_transaction if you touch the dependent.
 
-The cache_counters do not play well with optimistic locking because they are updated with
-a direct SQL call to the database, so ActiveRecord instance remain unaware of the lock_version
-change and assume it came from another transaction.
+The cache_counters do not play well with optimistic locking because they are
+updated with a direct SQL call to the database, so ActiveRecord instance remain
+unaware of the lock_version change and assume it came from another transaction.
 
-You should not need to declare lock_version for any children that are declared as a dependency
-of the root node, since updates will also update the root nodes lock_version.  So if another
-transaction updates a child, root.lock_version should increment, and the first transaction
-should raise a StaleObject error when it too tries to update the child.
+You should not need to declare lock_version for any children that are declared
+as a dependency of the root node, since updates will also update the root nodes
+lock_version.  So if another transaction updates a child, root.lock_version
+should increment, and the first transaction should raise a StaleObject error
+when it too tries to update the child.
 
 If you override super in the model hierarchy you are mediating, you must pass your 
 override as a block to super or it will occur outside of mediation:
 
   def save