.. role:: strike
    :class: strike

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

----

(Subliminal Message)
====================

.. image:: images/stop.jpg

----

# whoami
========

Brian Neal <bgneal1@rockwellcollins.com>

Started at Rockwell Collins in July 1999

You might remember 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 (via *push* and *pull* operations).

----

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 "micro-commits"
  - With SVN, people often hold back until an entire feature is complete

- 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
  - Switching between branches will blow your mind

- 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 CVCS, 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
 
.. image:: images/split_geography.png

----

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

.. image:: images/flexible_workflows.png
 
----

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

- No support for path-based access control

  - With current tools, you either can access the full repo, or nothing

----

Introduction to Mercurial
=========================

- Overview
- Repositories & working directories
- Changesets
- Branches & Tags
- Example workflow
- Command overview

----

Mercurial Overview
==================

- Distributed Version Control System
- Free, open source software licensed under GPL Version 2
- Available for Microsoft Windows, GNU/Linux, Mac OS X, Solaris 11 Express
- Written in Python with a small amount of C
- Extensible with official and 3rd party extensions
- TortoiseHg is a popular GUI for Windows
- Reputation for being fast & easy to get started with
- Can be served via Apache Web server
- Repository hooks
- Integrates with Trac
- Can import history from other tools, including Subversion

----

Repositories & Working Directories
==================================

A repository consists of two things:

- Your working directory (similar to a working copy in SVN)
- The repository itself (also known as "the store")

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

Example::

   $ ls -A
   .hg  .hgignore  images/  slides.cfg  slides.css  slides.html  slides.rst

- Repositories communicate via the *push* and *pull* commands

  - Push & Pull do not affect your working directory
  
    - An *update* or *merge* must be performed to receive remote changes into your working directory

----

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 (and infinite children)
- 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*, a special tag name

----

What's a Changeset?
===================

A changeset is an atomic collection of changes and some meta information. 
The meta information includes:

- Who made the changes
- When the changes were made
- Why - the commit message
- The name of the branch the changes were made on ("default" is the default)
- A local revision number
- A changeset ID; a 40 digit hex number (SHA-1 hash of the changeset & parents)

A changeset can be named by:

- Revision number (within a repository)
- Changeset ID (globally)
- Tag name

----

Branches & Tags
===============

- In the simple case, each changeset appear in a line
- When a changeset develops 2 or more children, a branch occurs

  - The latest revision of a branch is called a *head*
  - A *merge* is when two branches join back together
  - Branches can be given names; the default branch name is *"default"*

- Changesets can be given human readable names, or *tags*

  - *Local tags* are only visible within a repository
  - *Regular tags* are revision controlled and propagate to other repos 
  - The newest head in a repository is a tag called *tip*

----

Example Workflow
================

.. image:: images/workflow1.png

----

Example Workflow (cont.)
========================

.. image:: images/workflow2.png

----

Example Workflow (cont.)
========================

.. image:: images/workflow3.png

- Notice that after Alice's pull:
  
  - Her working directory is unaffected
  - Her repository only has one head => no merging required
  

----

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

Basic SVN commands:

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

----

Basic Mercurial Commands
========================

Mercurial (hg) vs SVN commands:

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

Additional "distributed commands":

- **clone**, **push**, **pull**
- **incoming**, **outgoing**

**Not a whole lot to learn above SVN**

----

References
==========

- Mercurial http://mercurial.selenic.com/
- Mercurial Wiki http://mercurial.selenic.com/wiki/
- Mercurial Book (free!) http://hgbook.red-bean.com/
- Hg Init: A Mercurial Tutorial http://hginit.com
- Version Control By Example (free!) http://www.ericsink.com/vcbe/

This presentation is available at::

   $ hg clone https://bitbucket.org/bgneal/dvcs_intro_brownbag

----

Questions?
==========