.. role:: strike
    :class: strike

Introduction to Distributed Version Control with Mercurial
==========================================================

----

(Sublimal Message)
==================

(We should be using this at work... )
-------------------------------------

(Seriously... )

----


# whoami
========

Brian Neal <bgneal1@rockwellcollins.com>

Started at Rockwell Collins in July 1999

Perhaps you've recognized me from the following programs:

- UMS (July 1999 - Spring 2000)
- Surgical Strike - (Spring - Fall 2000)
- JTRS 2B - (Fall 2000 - Summer 2001)
- SCAMP SEP - (Summer 2001 - October 2004)
- TTNT (January 2005 - Present)

----

Brief History of Version Control Tools
======================================

First Generation
----------------

- No networking!
- Concurrency method: locks
- Examples:
  
  - SCCS - 1972
  - RCS - 1982 

----

Brief History of Version Control Tools
======================================

Second Generation
-----------------

- Client/Server networking; CVCS (Centralized Version Control)
- Concurrency method: merge before commit
- Examples:
  
  - CVS - 1990
  - IBM Rational ClearCase - 1992
  - Visual SourceSafe - 1994
  - Perforce - 1995
  - SVN - 2000

----

Brief History of Version Control Tools
======================================

Third Generation
----------------

- Distributed networking; DVCS (Distributed Version Control)
- Concurrency method: commit then merge
- Examples:

  - Bitkeeper - 2000
  - Darcs - 2003
  - Monotone - 2003
  - Git - 2005
  - **Mercurial** - 2005
  - Fossil - 2006
  - Bazaar - 2007
  - Veracity - 2011

----

What is a CVCS Again?
=====================

.. image:: images/cvcs.png

----

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 locally!
  - 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
=========================

- Repositories & working copies
- Changesets
- Revisions, changesets, & heads
- Command overview
- Example workflow

----

Repositories & Working Copies
=============================

A repository consists of two things:

- Your working copy (a directory tree of files)
- The repository itself (also known as "the store")

  - A .hg directory at the top of your working copy

Example::

   brian@gremmie:~/Documents/Rockwell/brownbags/dvcs/dvcs$ la
   .hg  .hgignore  images/  slides.cfg  slides.css  slides.html  slides.rst

----

What's in a Repository?
=======================

A repository consists of a directed, acyclic graph of *changesets*

.. image:: images/repos.png

- Each changeset can have 0, 1, or 2 parents
- A changeset with 0 parents is the root
- A changeset with 2 parents is the result of a merge
- The newest changeset is called the *tip*

----

SVN Commands for Review
=======================

Basic SVN commands:

- add, remove, copy, move, mkdir
- checkout, commit, update, revert
- merge, resolved, diff
- status
- lock, unlock

----

Mercurial Commands
==================

Mercurial (hg) vs SVN commands:

- add, remove, copy, move, :strike:`mkdir`
- :strike:`checkout`, commit, update, revert
- merge, resolve, diff
- status
- :strike:`lock, unlock`

Additional "distributed commands":

- clone, push, pull
- incoming, outgoing
- serve