--- a/slides.rst	Mon Jun 25 18:50:42 2012 -0500
+++ b/slides.rst	Mon Jun 25 19:51:34 2012 -0500
@@ -6,10 +6,12 @@
 
 ----
 
-(Subliminal Message)
-====================
+Agenda
+======
 
-.. image:: images/stop.jpg
+- Brief history of version control tools
+- Features of distributed version control
+- Brief introduction to Mercurial
 
 ----
 
@@ -30,6 +32,36 @@
 
 ----
 
+Disclaimers
+===========
+
+- This is not a sales pitch
+- I actually :strike:`like` respect Subversion
+
+  - I'm the "Subversion guy" on my team
+  - I developed SVN training and have given it ~9-10 times
+  - http://subversion.tigris.org/issues/show_bug.cgi?id=3919
+
+- I am not an expert
+
+  - I'm probably making this look too easy
+
+----
+
+Why learn about DVCS?
+=====================
+
+- DVCS have exploded in the open source world
+
+  - Interestingly, Subversion is growing in corporate environments
+
+- Frustration with current tools
+- Interesting to see how the tools have evolved
+
+  - As a software practitioner, you should know what your options are
+
+----
+
 Brief History of Version Control Tools
 ======================================
 
@@ -157,7 +189,7 @@
 - Initial pull down of an entire repository *might* be slower than a CVCS
 
   - Then again, you might be surprised
-  - Mercurial, for example, stores an entire repository in less space than
+  - Mercurial, for example, stores an *entire* repository in less space than
     a SVN working copy in many cases
 
  
@@ -182,7 +214,7 @@
 - The remote location is stuck with network latency & associated problems
 - With a DVCS, each site can have a central repository
 
-  - The two central repos can be synched when convenient or even scripted
+  - The two central repos can be synch'ed when convenient or even scripted
  
 .. image:: images/split_geography.png
 
@@ -221,9 +253,10 @@
   - Some of this is not warranted...
 
     - Merge tracking was added in SVN v1.5
+    - Steadily improved in v1.6 - v1.7
 
   - SVN does not handle file renames and tree conflicts very well
-  - A lot of teams simply avoid merging out of fear
+  - A lot of teams simply avoid merging out of fear or superstition
 
 ----
 
@@ -236,7 +269,7 @@
 
     - More attention was paid to this aspect by DVCS's
 
-  - DVCS's use directed acyclic graphs internally to represent change sets
+  - DVCS's use **directed acyclic graphs** internally to represent change sets
 
     - More information is available to make merge decisions
     - Easier to find common ancestors of code
@@ -253,7 +286,7 @@
 - With a CVCS:
 
   - You make changes in your working copy
-  - Before you can commit, you often must peform an update
+  - Before you can commit, you often must perform an update
      
     - This may trigger a merge
     - Your changes are now mixed up with your friendly coworkers' changes
@@ -281,11 +314,11 @@
 
 - Huge repositories are not practical
 
-- Hetrogenous repositories are not practical
+- Heterogeneous repositories are not practical
 
   - Not a good idea to mix, say, software, systems, and firmware in the same repo
   - Not a good idea to mix multiple products in the same repo
-  - Arguably, this applies to a CVCS as well
+  - *Arguably, this applies to a CVCS as well*
 
 - No support for path-based access control
 
@@ -317,7 +350,7 @@
 - Reputation for being fast & easy to get started with
 - Can be served via Apache Web server
 - Repository hooks
-- Integrates with Trac
+- Integrates with the Trac issue tracker
 - Can import history from other tools, including Subversion
 
 ----
@@ -398,6 +431,48 @@
 
 ----
 
+A note on branching...
+======================
+
+- Branching happens *all the time* when multiple developers are involved
+- It is so natural you may not notice it at first
+- Branching often has two meanings:
+
+  - The "normal" day-to-day branching when developers combine changes
+  - The conceptual branching that occurs when:
+
+    - You need a feature branch
+    - You need a release branch
+    - You need an experimental branch
+    - etc.
+
+----
+
+Ways to Branch in Hg
+====================
+
+- Just make another clone of the repository!
+
+  - Slowest, safest, easiest to understand
+  - Hard links are used (where available) to minimize disk space
+
+- Bookmarks
+
+  - Lightweight tags can be applied to changesets
+  - Similar to how Git does branches
+  - Bookmarks can be deleted; they are not permanent
+
+- Named branches
+
+  - Actually recording the branch name in the changeset
+
+- Anonymous branches
+  
+  - Update to any old changeset, make changes, commit
+  - "Good" for emergency fixes, bad for remembering what you did
+
+----
+
 Example Workflow
 ================