Distributed Version Control with Mercurial and git

Distributed Version Control with

Mercurial and git

Hannes Hirzel

This work is produced by OpenStax-CNX and licensed under the Creative Commons Attribution License 3.0†

Abstract

The module gives a short introduction what version control is, lists some well known systems and then leads to learning the basics of the distributed version control system named 'Mercurial'.

1 What is a version control system?

When doing a project be it a programming project, web development or any project where you keep the information in les in a directory and it's sub-directories you might need a version control system. Because whenever you change a le the existing version is overwritten. No record of past versions is kept unless you do it manually by keeping dierent versions of the same le. A version control system automatically keeps all earlier versions. You only see and work with the current version, all earlier versions are kept at a hidden place.

The result of this is that in case you introduce an error you may go back to an earlier version and recover from it. If people work together in a team it is easy to see who did a specic change.

Version control systems are also known under the name of revision control system or source code management system.

A project is a folder or directory which contains the les for which earlier versions are kept. Well known version control systems:

SCCS Source Code

Con-trol System Bell Labs, MarcRochkind 1970 central repository

RCS Revision Control

System Walter Tichy Early 1980ties central repository

CVS Concurrent

Ver-sion Control

System

Dick Grune /

Brian Berliner Late 80ties central repository

continued on next page

∗_{Version 1.12: Aug 31, 2013 12:33 pm -0500} †_{http://creativecommons.org/licenses/by/3.0/}

svn Apache Subversion Jim Blandy and

Karl Fogel 2001 central repository

hg Mercurial Matt Mackall 2005 Distributed

bzr Bazaar Martin Pool 2007 Distributed

git Git Linus Torvalds 2005 Distributed

Table 1

note: Oce programs have simple built-in version control systems as well. Traditional version control systems

In traditional centralized version control systems like SCCS, RCS, CVS ans svn you have a central data store (le system) where people "check-out" and "check-in" the les with which they are working.

2 What is a distributed version control system?

In a distributed version control system like in git or Mercurial there is not necessarily a central repository (client server setup) though you have the option of setting up a work ow where you keep a central repository. Each participant has his or her own copy or clone of the repository. The developers do not need to be in a common network. Patches of the changes are exchanged. This might happen through the net (LAN, Internet), physical media (e.g. pen drive) or even email.

So in a distributed version control system the emphasis is on moving around "changes", i.e. the informa-tion which les have changed with the actual change. People speak of "pulling" changes from a repository and "pushing" their own changes back to a repository. In addition "branches" are created which later might be "merged" again.

tip: There is an open content book1 _{about the git distributed version control system. To install it}

under Debian based Linux use sudo apt-get install git-core or for Windows http://msysgit.github.io/2 git tutorial

50 page tutorial3_{to learn to use git.} git concepts4

3 Mercurial

In the rest of this module we focus on the Mercurial version control system. It is fairly easy to learn. With a few commands you can accomplish basic version control task and at the same time it scales well. Comparing dierent distributed version control systems is out of the scope of this module.

The Denitive Guide

At this moment it is recommend that you continue reading the on-line book 'Mercurial: The Denitive Guide'5 _{by Bryan O'Sullivan. The book is published on paper as well by O'Reilly. The rst 6 chapters are} sucient to get you started for straightforward project work as a single programmer or in a two or three person team.

1. How did we get here? (why revision control, about forking)

1_{http://git-scm.com/doc}

2_{http://code.google.com/p/msysgit} 3_{http://gitimmersion.com}

4_{http://www.sbf5.com/∼cduan/technical/git/} 5_{http://hgbook.red-bean.com/read/}

2. A tour of Mercurial: the basics (installation, help, clone, user name, making and reviewing changes, commit, status)

3. A tour of Mercurial: merging work (hg pull, hg heads, hg merge, hg update, hg commit) 4. Behind the scenes (revision history, branching, merging, working directory)

5. Mercurial in daily use (hg add, hg remove)

6. Collaborating with other people (models, work ow)

Later on you might want to read the remaining 8 chapters. The focus is on learning to operate it from the command line. There are Graphical user interfaces for it on the dierent platforms. Noteworthy is the hg server command which runs a local web server which serves les to browse the revision history.

Installation

MSWindows: TortoiseHG http://tortoisehg.org/6 Debian: sudo apt-get install mercurial More7 _{on installation.}

4 Summary of basic Mercurial commands

When you just type hg (the command for Mercurial) you get a list of the basic commands. Mercurial Distributed SCM

basic commands:

add add the specified files on the next commit annotate show changeset information by line for each file clone make a copy of an existing repository

commit commit the specified files or all outstanding changes diff diff repository (or selected files)

export dump the header and diffs for one or more changesets forget forget the specified files on the next commit

init create a new repository in the given directory log show revision history of entire repository or files merge merge working directory with another revision pull pull changes from the specified source

push push changes to the specified destination remove remove the specified files on the next commit serve export the repository via HTTP

status show changed files in the working directory summary summarize working directory state

update update working directory

use "hg help" for the full list of commands or "hg -v" for details

Actually all of them are used when working with Mercurial. To get an understanding of the concept clone, pull, push, merge, commit and update are important.

Help information for 'log' command hg help log for example shows

6_{http://tortoisehg.org/}

hg log [OPTION]... [FILE] aliases: history

show revision history of entire repository or files

Print the revision history of the specified files or the entire project. File history is shown without following rename or copy history of files. Use -f/--follow with a filename to follow history across renames and copies. --follow without a filename will only show ancestors or descendants of the starting revision. --follow-first only follows the first parent of merge revisions.

If no revision range is specified, the default is tip:0 unless --follow is set, in which case the working directory parent is used as the starting revision.

See 'hg help dates' for a list of formats valid for -d/--date.

By default this command prints revision number and changeset id, tags, non-trivial parents, user, date and time, and a summary for each commit. When the -v/--verbose switch is used, the list of changed files and full commit message are shown.

NOTE: log -p/--patch may generate unexpected diff output for merge

changesets, as it will only compare the merge changeset against its first parent. Also, only files different from BOTH parents will appear in files:.

pull command

Help information for the hg help pull command

hg pull [-u] [-f] [-r REV]... [-e CMD] [--remotecmd CMD] [SOURCE] pull changes from the specified source

Pull changes from a remote repository to a local one.

This finds all changes from the repository at the specified path or URL and adds them to a local repository (the current one unless -R is specified). By default, this does not update the copy of the project in the working directory.

Use hg incoming if you want to see what would have been added by a pull at the time you issued this command. If you then decide to added those

changes to the repository, you should use pull -r X where X is the last changeset listed by hg incoming.

for more information. options:

-u --update update to new branch head if changesets were pulled -f --force run even when remote repository is unrelated

-r --rev a remote changeset intended to be added -b --branch a specific branch you would like to pull -e --ssh specify ssh command to use

--remotecmd specify hg command to run on the remote side use "hg -v help pull" to show global options

5 Locations of the repositories

As a minimum you might want to keep the repositories just in dierent directories on your local machine and use one of them to merge the changes from other repositories into it. Or if you work together with a colleague you might want to exchange with him or her through a USB drive or shared network drive or through a Mercurial server set up in your LAN or a hosting service in the internet. A hosting service which is free for small projects is www.bitbucket.org8_{. It as well contains good tutorials with which you might want} to start before having read the book mentioned above. However reading 'The Denitive Guide' is worth the eort if you want to go beyond trial examples and get a good understanding.

Mercurial maintains a ".hg" directory in which it keeps the version history information.

6 HgInit: Set up for a Team (example)

http://hginit.com/top/02.html9

8_{http://www.bitbucket.org/} 9_{http://hginit.com/top/02.html}