All repositories are peers. By convention only, one repository is designated the master.
bgneal@13: It is possible for all peers to exchange changes (via push and pull operations).
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Presenter Notes
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
What does a DVCS buy you?
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Private workspaces
bgneal@13:
Offline mode
bgneal@13:
Speed
bgneal@13:
Scalability
bgneal@13:
Split Geography
bgneal@13:
Flexible workflows
bgneal@13:
Distributed backups
bgneal@13:
Easier merging
bgneal@13:
Commit before merge
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Presenter Notes
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Private Workspaces
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
You can safely experiment in your local repository
bgneal@13:
Commit as often as you like without affecting the team
bgneal@13:
Encourages "micro-commits"
bgneal@13:
With SVN, people often hold back until an entire feature is complete
bgneal@13:
bgneal@13:
bgneal@13:
Encourages experimentation
bgneal@13:
Make cheap repository clones to try things out
bgneal@13:
Not visible to coworkers
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Presenter Notes
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Offline Mode
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Work when you have spotty or no network access
bgneal@13:
Full access to the repo when offline
bgneal@13:
Can work on multiple tasks offline
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Work on bug report #1
bgneal@13:
Commit
bgneal@13:
Work on bug report #2
bgneal@13:
With a CVCS, you'd have both fixes in the same pending commit
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Presenter Notes
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Speed
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Local operations are fast
bgneal@13:
No, really, you will notice a big difference
bgneal@13:
Switching between branches will blow your mind
bgneal@13:
bgneal@13:
bgneal@13:
Initial pull down of an entire repository might be slower than a CVCS
bgneal@13:
Then again, you might be surprised
bgneal@16:
Mercurial, for example, stores an entire repository in less space than
bgneal@13: a SVN working copy in many cases
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Presenter Notes
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Scalability
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Some CVCS systems require heavy weight hardware to support the server
bgneal@13:
E.g. ClearCase with a thousand users
bgneal@13:
With a DVCS, only pushes & pulls contact a central server
bgneal@13:
Most of the work is done locally
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Presenter Notes
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Split Geography
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Imagine a team split between Cedar Rapids & Richardson...
bgneal@13:
With a CVCS, you have to pick where to put the server
bgneal@13:
The remote location is stuck with network latency & associated problems
bgneal@13:
With a DVCS, each site can have a central repository
bgneal@16:
The two central repos can be synch'ed when convenient or even scripted
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Presenter Notes
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Flexible Workflows
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
There is no internal concept of a central repository
bgneal@13:
A central repository exits only by convention
bgneal@13:
More elaborate topologies and workflows can be created:
bgneal@13:
A SW team may push to a central SW repo
bgneal@13:
Periodically changes from the SW repo are pushed to a QA repo
bgneal@13:
Changes from the QA repo can be pushed into a release repo
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Presenter Notes
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Distributed Backups
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
With a DVCS, multiple copies of the repository exist on multiple machines
bgneal@13:
Of course, this is no substitute for a real backup strategy!
bgneal@13:
But usually, and with short notice, you can easily designate a repository as
bgneal@13: the central repository in an emergency
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Presenter Notes
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Easier Merging
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Subversion has a bad reputation for merging
bgneal@13:
Some of this is not warranted...
bgneal@13:
Merge tracking was added in SVN v1.5
bgneal@16:
Steadily improved in v1.6 - v1.7
bgneal@13:
bgneal@13:
bgneal@13:
SVN does not handle file renames and tree conflicts very well
bgneal@16:
A lot of teams simply avoid merging out of fear or superstition
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Presenter Notes
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Easier Merging (cont.)
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Why is merging better in a DVCS?
bgneal@13:
Merging simply has to work correctly and be easy in a DVCS
bgneal@13:
More attention was paid to this aspect by DVCS's
bgneal@13:
bgneal@13:
bgneal@16:
DVCS's use directed acyclic graphs internally to represent change sets
bgneal@13:
More information is available to make merge decisions
bgneal@13:
Easier to find common ancestors of code
bgneal@13:
bgneal@13:
bgneal@13:
Developer changes and merge changes are separate
bgneal@13:
"Commit before merge"
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Presenter Notes
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Commit Before Merge
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
With a CVCS:
bgneal@13:
You make changes in your working copy
bgneal@16:
Before you can commit, you often must perform an update
bgneal@13:
This may trigger a merge
bgneal@13:
Your changes are now mixed up with your friendly coworkers' changes
bgneal@13:
Sometimes this can be a problem...
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
With a DVCS:
bgneal@13:
You make changes in your working copy
bgneal@13:
You commit locally!
bgneal@13:
You can then choose to pull changes from others and merge
bgneal@13:
Your changes are already safely tucked away and can be retrieved later if things go wrong
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Presenter Notes
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Okay, what's the catch?
bgneal@13:
bgneal@13:
bgneal@13:
Potential drawbacks to a DVCS
bgneal@13:
bgneal@13:
Practically no support for locks
bgneal@13:
This makes working with binary files difficult in a team environment
bgneal@13:
bgneal@13:
bgneal@13:
Huge repositories are not practical
bgneal@16:
Heterogeneous repositories are not practical
bgneal@13:
Not a good idea to mix, say, software, systems, and firmware in the same repo
bgneal@13:
Not a good idea to mix multiple products in the same repo
bgneal@16:
Arguably, this applies to a CVCS as well
bgneal@13:
bgneal@13:
bgneal@13:
No support for path-based access control
bgneal@13:
With current tools, you either can access the full repo, or nothing
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Presenter Notes
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Introduction to Mercurial
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Overview
bgneal@13:
Repositories & working directories
bgneal@13:
Changesets
bgneal@13:
Branches & Tags
bgneal@13:
Example workflow
bgneal@13:
Command overview
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Presenter Notes
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Mercurial Overview
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Distributed Version Control System
bgneal@13:
Free, open source software licensed under GPL Version 2
bgneal@13:
Available for Microsoft Windows, GNU/Linux, Mac OS X, Solaris 11 Express
bgneal@13:
Written in Python with a small amount of C
bgneal@13:
Extensible with official and 3rd party extensions
bgneal@13:
TortoiseHg is a popular GUI for Windows
bgneal@13:
Reputation for being fast & easy to get started with
bgneal@13:
Can be served via Apache Web server
bgneal@13:
Repository hooks
bgneal@16:
Integrates with the Trac issue tracker
bgneal@13:
Can import history from other tools, including Subversion
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Presenter Notes
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Repositories & Working Directories
bgneal@13:
bgneal@13:
bgneal@13:
A repository consists of two things:
bgneal@13:
bgneal@13:
Your working directory (similar to a working copy in SVN)
bgneal@13:
The repository itself (also known as "the store")
bgneal@13:
A .hg directory at the top of your working copy
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Example:
bgneal@13:
bgneal@13: $ ls -A
bgneal@13: .hg .hgignore images/ slides.cfg slides.css slides.html slides.rst
bgneal@13:
bgneal@13:
bgneal@13:
Repositories communicate via the push and pull commands
bgneal@13:
Push & Pull do not affect your working directory
bgneal@13:
An update or merge must be performed to receive remote changes into your working directory
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Presenter Notes
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
What's in a Repository?
bgneal@13:
bgneal@13:
bgneal@13:
A repository consists of a directed, acyclic graph of changesets
bgneal@13:
bgneal@13:
bgneal@13:
Each changeset can have 0, 1, or 2 parents (and infinite children)
bgneal@13:
A changeset with 0 parents is the root
bgneal@13:
A changeset with 2 parents is the result of a merge
bgneal@13:
The newest changeset is called the tip, a special tag name
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Presenter Notes
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
What's a Changeset?
bgneal@13:
bgneal@13:
bgneal@13:
A changeset is an atomic collection of changes and some meta information.
bgneal@13: The meta information includes:
bgneal@13:
bgneal@13:
Who made the changes
bgneal@13:
When the changes were made
bgneal@13:
Why - the commit message
bgneal@13:
The name of the branch the changes were made on ("default" is the default)
bgneal@13:
A local revision number
bgneal@13:
A changeset ID; a 40 digit hex number (SHA-1 hash of the changeset & parents)
bgneal@13:
bgneal@13:
A changeset can be named by:
bgneal@13:
bgneal@13:
Revision number (within a repository)
bgneal@13:
Changeset ID (globally)
bgneal@13:
Tag name
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Presenter Notes
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Branches & Tags
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
In the simple case, each changeset appear in a line
bgneal@13:
When a changeset develops 2 or more children, a branch occurs
bgneal@13:
The latest revision of a branch is called a head
bgneal@13:
A merge is when two branches join back together
bgneal@13:
Branches can be given names; the default branch name is "default"
bgneal@13:
bgneal@13:
bgneal@13:
Changesets can be given human readable names, or tags
bgneal@13:
Local tags are only visible within a repository
bgneal@13:
Regular tags are revision controlled and propagate to other repos
bgneal@13:
The newest head in a repository is a tag called tip
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
Presenter Notes
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@13:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
A note on branching...
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
Branching happens all the time when multiple developers are involved
bgneal@16:
It is so natural you may not notice it at first
bgneal@16:
Branching often has two meanings:
bgneal@16:
The "normal" day-to-day branching when developers combine changes
bgneal@16:
The conceptual branching that occurs when:
bgneal@16:
You need a feature branch
bgneal@16:
You need a release branch
bgneal@16:
You need an experimental branch
bgneal@16:
etc.
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
Presenter Notes
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
Ways to Branch in Hg
bgneal@16:
bgneal@16:
bgneal@16:
bgneal@16:
Just make another clone of the repository!
bgneal@16:
Slowest, safest, easiest to understand
bgneal@16:
Hard links are used (where available) to minimize disk space
bgneal@16:
bgneal@16:
bgneal@16:
Bookmarks
bgneal@16:
Lightweight tags can be applied to changesets
bgneal@16:
Similar to how Git does branches
bgneal@16:
Bookmarks can be deleted; they are not permanent
bgneal@16:
bgneal@16:
bgneal@16:
Named branches
bgneal@16:
Actually recording the branch name in the changeset
bgneal@16:
bgneal@16:
bgneal@16:
Anonymous branches
bgneal@16:
Update to any old changeset, make changes, commit
bgneal@16:
"Good" for emergency fixes, bad for remembering what you did