# HG changeset patch # User Brian Neal # Date 1322700392 21600 # Node ID 3547bba86af26f68c652e77636dc3d00a8ea6a10 # Parent 727c48601d663b458b8709b832392d32cbab850f Removed *.html from .hgignore because we are using our own theme now (that includes a base.html file), and it is convenient to control the generated presentation since I won't necessarily have Python and landslide installed on every computer I want to give the presentation. diff -r 727c48601d66 -r 3547bba86af2 .hgignore --- a/.hgignore Wed Nov 30 18:44:44 2011 -0600 +++ b/.hgignore Wed Nov 30 18:46:32 2011 -0600 @@ -1,4 +1,3 @@ syntax: glob *.pyc *.swp -*.html diff -r 727c48601d66 -r 3547bba86af2 my_theme/base.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/my_theme/base.html Wed Nov 30 18:46:32 2011 -0600 @@ -0,0 +1,182 @@ + + + + + + + {{ head_title }} + + {% if embed %} + + + {% else %} + + + {% endif %} + {% for css in user_css %} + {% if embed %} + + {% else %} + + {% endif %} + {% endfor %} + + + {% if embed %} + + {% else %} + + {% endif %} + {% for js in user_js %} + {% if embed %} + + {% else %} + + {% endif %} + {% endfor %} + + + +
+
+
+
+
+
+ {% for slide in slides %} + +
+
+
+ {% if slide.header %} +
{{ slide.header }}
+ {% endif %} + {% if slide.content %} +
{{ slide.content }}
+ {% endif %} +
+
+

Presenter Notes

+
+ {% if slide.presenter_notes %} + {{ slide.presenter_notes }} + {% endif %} +
+
+ +
+
+ {% endfor %} +
+
+ {% if toc %} + + {% endif %} + + + + diff -r 727c48601d66 -r 3547bba86af2 slides.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/slides.html Wed Nov 30 18:46:32 2011 -0600 @@ -0,0 +1,1599 @@ + + + + + + + Introduction to Distributed Version Control with Mercurial + + + + + + + + + + + + + + + + + + + +
+
+
+
+
+
+ + +
+
+
+ +

Introduction to Distributed Version Control with Mercurial

+ + +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

(Subliminal Message)

+ + +
images/stop.jpg
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

# 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)
    • +
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

Brief History of Version Control Tools

+ + +

First Generation

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

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

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
      • +
    +
    • +
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

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
      • +
    +
    • +
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

What is a CVCS Again?

+ + +
images/cvcs.png
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

So what's a DVCS look like?

+ + +
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).

+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

What does a DVCS buy you?

+ + +
    +
  • Private workspaces
    • +
  • Offline mode
    • +
  • Speed
    • +
  • Scalability
    • +
  • Split Geography
    • +
  • Flexible workflows
    • +
  • Distributed backups
    • +
  • Easier merging
    • +
  • Commit before merge
    • +
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

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
      • +
    +
    • +
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

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
    • +
+
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

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
      • +
    +
    • +
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

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
      • +
    +
    • +
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

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
      • +
    +
    • +
+images/split_geography.png
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

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
      • +
    +
    • +
+images/flexible_workflows.png
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

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
    • +
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

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
      • +
    +
    • +
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

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"
        • +
      +
      • +
    +
    • +
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

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
        • +
      +
      • +
    +
    • +
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

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
      • +
    +
    • +
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

Introduction to Mercurial

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

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

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
    • +
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

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
        • +
      +
      • +
    +
    • +
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

What's in a Repository?

+ + +

A repository consists of a directed, acyclic graph of changesets

+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
    • +
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

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
    • +
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

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
      • +
    +
    • +
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

Example Workflow

+ + +
images/workflow1.png
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

Example Workflow (cont.)

+ + +
images/workflow2.png
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

Example Workflow (cont.)

+ + +
images/workflow3.png +
    +
  • Notice that after Alice's pull:
      +
    • Her working directory is unaffected
      • +
    • Her repository only has one head => no merging required
      • +
    +
    • +
+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

SVN Commands for Review

+ + +

Basic SVN commands:

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

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

Basic Mercurial Commands

+ + +

Mercurial (hg) vs SVN commands:

+
    +
  • add, remove, copy, move, mkdir
    • +
  • checkout, commit, update, revert
    • +
  • merge, resolve, diff, heads
    • +
  • status, log
    • +
  • lock, unlock
    • +
+

Additional "distributed commands":

+
    +
  • clone, push, pull
    • +
  • incoming, outgoing
    • +
+

Not a whole lot to learn above SVN

+ +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

References

+ + +
+

This presentation is available at:

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

Presenter Notes

+
+ +
+
+ +
+
+ + +
+
+
+ +

Questions?

+ + +
+
+

Presenter Notes

+
+ +
+
+ +
+
+ +
+
+ + + + + + + \ No newline at end of file