Binary file images/dvcs.png has changed

--- a/slides.rst	Tue Nov 08 20:52:15 2011 -0600
+++ b/slides.rst	Wed Nov 09 21:06:05 2011 -0600
@@ -95,6 +95,203 @@
 
 ----
 
+So what's a DVCS look like?
+===========================
+
+.. image:: images/dvcs.png
+
+All repositories are peers. By convention only, one repository is designated the master.
+It is possible for all peers to exchange changes.
+
+----
+
+What does a DVCS buy you?
+=========================
+
+- Private workspaces
+- Offline mode
+- Speed
+- Scalability
+- Split Geography
+- Flexible workflows
+- Distributed backups
+- **Easier merging**
+- **Commit before merge**
+
+----
+
+Private Workspaces
+==================
+
+- You can safely experiment in your local repository
+- Commit as often as you like without affecting the team
+- Encourages experimentation
+
+  - Make cheap repository clones to try things out
+  - Not visible to coworkers
+
+----
+
+Offline Mode
+============
+  
+- Work when you have spotty or no network access
+- Full access to the repo when offline
+- Can work on multiple tasks offline
+
+ - Work on bug report #1
+ - Commit
+ - Work on bug report #2
+ - With a CVCS, you'd have both fixes in the same pending commit
+ 
+----
+
+Speed
+=====
+
+- Local operations are **fast**
+- No, really, **you will** notice a big difference
+- 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
+    a SVN working copy in many cases
+ 
+----
+
+Scalability
+===========
+
+- Some CVCS systems require heavy weight hardware to support the server
+
+  - E.g. ClearCase with a thousand users
+  - With a DVCS, only pushes & pulls contact a central server
+  - Most of the work is done locally
+
+----
+
+Split Geography
+===============
+
+- Imagine a team split between Cedar Rapids & Richardson
+- With a CVS, you have to pick where to put the server
+- 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
+ 
+----
+
+Flexible Workflows
+==================
+
+- There is no internal concept of a central repository
+- A central repository exits only by convention
+- More elaborate topologies and workflows can be created:
+
+  - A SW team may push to a central SW repo
+  - Periodically changes from the SW repo are pushed to a QA repo
+  - Changes from the QA repo can be pushed into a release repo
+ 
+----
+
+Distributed Backups
+===================
+
+- With a DVCS, multiple copies of the repository exist on multiple machines
+- **Of course, this is no substitute for a real backup strategy!**
+- But usually, and with short notice, you can easily designate a repository as
+  the central repository in an emergency
+ 
+----
+
+Easier Merging
+==============
+
+- Subversion has a bad reputation for merging
+
+  - Some of this is not warranted...
+
+    - Merge tracking was added in SVN v1.5
+
+  - SVN does not handle file renames and tree conflicts very well
+  - A lot of teams simply avoid merging out of fear
+
+----
+
+Easier Merging (cont.)
+======================
+
+- Why is merging better in a DVCS?
+
+  - Merging simply has to work correctly and be easy in a DVCS
+
+    - More attention was paid to this aspect by DVCS's
+
+  - 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
+
+  - Developer changes and merge changes are separate
+
+    - "Commit before merge"
+ 
+----
+
+Commit Before Merge
+===================
+
+- With a CVCS:
+
+  - You make changes in your working copy
+  - Before you can commit, you often must peform an update
+     
+    - This may trigger a merge
+    - Your changes are now mixed up with your friendly coworkers' changes
+    - Sometimes this can be a problem...
+
+- With a DVCS:
+
+  - You make changes in your working copy
+  - You commit!
+  - You can then choose to pull changes from others and merge
+
+    - **Your changes are already safely tucked away and can be retrieved later if things go wrong**
+
+----
+
+Okay, what's the catch?
+=======================
+
+Potential drawbacks to a DVCS
+-----------------------------
+
+- Practically no support for locks
+
+  - This makes working with binary files difficult in a team environment
+
+- Huge repositories are not practical
+
+- Hetrogenous 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
+
+----
+
+Introduction to Mercurial
+=========================
+
+- Command overview
+- Repositories & working copies
+- Changesets
+- Revisions, changesets, & heads
+- Example workflow
+
+----
+
 What is a CVCS Again?
 =====================
 
@@ -111,16 +308,6 @@
 So what's a DVCS look like?
 ===========================
 
-.. image:: images/dvcs.png
-
-All repositories are peers. By convention only, one repository is designated the master.
-It is possible for all peers to exchange changes.
-
-----
-
-So what's a DVCS look like?
-===========================
-
 Mercurial (hg) vs SVN commands:
 
 - add, remove, copy, move, :strike:`mkdir`