OpenStax-CNX module: m37404 1 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 Control RCS Revision Control CVS Concurrent Version Control Bell Labs, Marc Rochkind 1970 central repository Walter Tichy Early 1980ties central repository 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/
OpenStax-CNX module: m37404 2 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 information 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 book 1 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 tutorial 3 to learn to use git. git concepts 4 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/
OpenStax-CNX module: m37404 3 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 More 7 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 annotate clone commit diff export forget init log merge pull push remove serve status summary update add the specified files on the next commit show changeset information by line for each file make a copy of an existing repository commit the specified files or all outstanding changes diff repository (or selected files) dump the header and diffs for one or more changesets forget the specified files on the next commit create a new repository in the given directory show revision history of entire repository or files merge working directory with another revision pull changes from the specified source push changes to the specified destination remove the specified files on the next commit export the repository via HTTP show changed files in the working directory summarize working directory state 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/ 7 http://git-scm.com/book/en/getting-started-installing-git
OpenStax-CNX module: m37404 4 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. If SOURCE is omitted, the 'default' path will be used. See 'hg help urls'
OpenStax-CNX module: m37404 5 options: for more information. -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.org 8. 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.html 9 8 http://www.bitbucket.org/ 9 http://hginit.com/top/02.html