An Introduction to Mercurial Version Control Software LANS Weekly - - PowerPoint PPT Presentation

▶
an introduction to mercurial version control software
SMART_READER_LITE
LIVE PREVIEW

An Introduction to Mercurial Version Control Software LANS Weekly - - PowerPoint PPT Presentation

Jul 30, 2023 184 likes •432 views

An Introduction to Mercurial Version Control Software LANS Weekly Seminar October 17, 2006 Satish Balay balay@mcs.anl.gov Outline Why use version control? Simple example of revisioning Mercurial introduction - Local usage -

slide-1
SLIDE 1

An Introduction to Mercurial Version Control Software

LANS Weekly Seminar October 17, 2006 Satish Balay balay@mcs.anl.gov

slide-2
SLIDE 2

Outline

  • Why use version control?
  • Simple example of revisioning
  • Mercurial introduction
  • Local usage
  • Remote usage
  • Normal user workflow
  • Organizing repositories [clones]
  • Mercurial at MCS
  • [Demo]
slide-3
SLIDE 3

What do we use Version Control for?

  • Keep track of changes to files
  • Enable multiple users editing files simultaneously
  • Go back and check old changes:

* what was the change * when was the change made * who made the change * why was the change made

  • Manage branches [release versions vs dev]
slide-4
SLIDE 4

Simple Example of Revisioning

main.c main.c 1 2 3 File Version File Changes Delta

slide-5
SLIDE 5

Simple Example Cont.

Repository Version

  • 1

main.c main.c 1 2 3 main.c main.c main.c makefile 1 3 1 2 Changeset

slide-6
SLIDE 6

Some Definitions

  • Delta: a single change [to a file]
  • Changeset: a collection of deltas [perhaps to

multiple files] that are collectively tracked.

  • Repository: collection of files we intend to keep

track of. This includes the revision history

  • Version [or Source] Control Tool: Enables us to

keep track of all the changes [to files] in a repository

slide-7
SLIDE 7

Mercurial

  • Distributed version control tool.
  • http://www.selenic.com/mercurial
  • OpenSource [GPL]
  • Active mailing list : mercurial@selenic.com
  • Written in python
  • Works on linux, windows, and other machines
  • Reasonably efficient [handles 9000+ changesets

in PETSc]

slide-8
SLIDE 8

Usage: Creating a Repository

  • mkdir project
  • cd project
  • hg init
  • Initializes the directory 'project' as a mercurial repo.
  • All 'hg' commands are invoked inside the repository
  • All commands are in the form 'hg command'. For

example : hg help

  • Stores metadata in the subdirectory project/.hg
slide-9
SLIDE 9

Usage: Adding/Modifying Files

  • cd project
  • touch main.c
  • hg add main.c
  • hg commit
  • emacs main.c [edits to file]
  • hg commit [alternative: hg ct ]
  • 'add' indicates the file is now part of the repository.
  • 'commit' creates a changeset for the current changes.

[prompts the user to enter comments]

slide-10
SLIDE 10

Repository Data vs Working Files

  • Repository data is the revision history and graph of all the
  • changes. Its stored in project/.hg directory
  • Working files are the reset of the files in project. User

edits the working files.

  • hg tip [show the tip revision of the repository graph]
  • hg parent [show the parent revision of the working dir]

Note: Working dir files can correspond to any revision of the repository. So one has to be careful about this point [and not assume the parent is always the tip revision]

  • hg update REV [update working copy to REV version]
slide-11
SLIDE 11

Illustration of Changes

repository working files metadata repository repository hg commit

file changes changeset

slide-12
SLIDE 12

Checking Status/History

  • hg status [list the current modified, unknown files]
  • hg diff [list the diff of the changed files in patch form]
  • hg log [list the revision history of all changes]
  • hg view [extension: GUI tool to check changeset graph]
  • hg ct [extension: GUI tool to commit changes]

Note: So far we have delt with local opeations on the repository

slide-13
SLIDE 13

Distributed Model

  • Peer to Peer: all copies of repositories are equivalent.
  • Information flows between repositories as changesets.
  • Each operation is between two repositories.
  • hg clone /home/balay/old-repo new-repo
  • cd new-repo [Local reposiory to invoke cmds]
  • hg pull [repo] [get remote changesets and apply locally]
  • hg push [repo] [apply local changes to the remote repo]

Notes:

  • Every repository has complete revision history [metadata]
  • One can switch roles of old-repo & new-repo
  • Remote operations between repositories [as oposed to local operations]
slide-14
SLIDE 14

URLs

hg help pull [documentation of urls]

  • /home/balay/petsc-dev
  • ssh://petsc@harley.mcs.anl.gov//home/petsc/petsc-dev
  • http://hg.mcs.anl.gov/petsc/petsc-dev [readonly]
  • http-old://www.mcs.anl.gov/~petsc/project [readonly]
  • https:// [read/write support in newer versions]

Note: 'hg clone' stores the URL for remote repository [in .hg/hgrc] – so, when push,pull are invoked, url is not

  • required. [versions 0.9.1 and newer]
slide-15
SLIDE 15

Organizing Repositories [clones]

Any to Any Shared Common Methods of communicating changes

  • clone/push/pull [changesets]
  • import/export [email patch]
  • bundle/unbundle [email changesets]

The relations are not hardcoded

slide-16
SLIDE 16

Syncing Two Repositories with Changesets to Remote Repository

repository-local working files metadata repository-remote repository-local repository-remote repository-local repository-remote Remote repo has extra changesets hg pull hg update

slide-17
SLIDE 17

Syncing Two Repositories with Changesets to Local Repository

repository-remote working files metadata repository-local repository-remote repository-local Local repo has extra changesets hg push Updating Working copy of remote is not necessary.

slide-18
SLIDE 18

Syncing Two Repositories with Changesets to both Repositories

repository-local working files metadata repository-remote repository-local repository-remote

B

Both repos have extra changesets hg pull

A B

repository-local repository-remote hg push repository-local repository-remote

B A+B

hg commit repository-local repository-remote

B

hg merge

B A+B A+B

RevisionGraph Change Initial A B Initial B Initial A

A+B

A A: local repo changeset B: remote repo changeset A+B: merge changeset

B B B A A A B A A

slide-19
SLIDE 19

Normal User Work Flow

  • <make changes to working files>
  • hg commit [commit local changes]
  • hg pull [check & obtain remote changes]
  • hg merge [auto merge – if not use external

merge tool for eg: kdiff3]

  • hg commit [commit the merge changeset]
  • hg push [push local changesets + merge

changesets to the remote repository]

slide-20
SLIDE 20

Handling Uncomitted Edits ?

  • Uncomited chages present with local changesets
  • Uncomited changes present with push/pull
  • Uncomited changes present during update/merge
  • More things need to be kept track off

[uncommited changes, commits, commits in the remote repository, merges etc..]

  • This is best avoided...
slide-21
SLIDE 21

Multiple Users: Communicating Changesets using a Shared Repository

petsc-dev balay-clone User CloneRepos Shared repository bsmith-clone temp-clone-2 external-user read only, via http read/write via ssh temp-clone-1 knepley-clone

slide-22
SLIDE 22

Managing Patches to Release Versions

petsc-dev petsc-release release-clone dev-clone Shared Repos User CloneRepos

  • 1. Apply fix
  • 2. Pull/Merge/Push to shared release repo
  • 3. Pull/merge [from dev-clone]
  • 4. Pull/Merge/Push to shared dev repo
slide-23
SLIDE 23

Browsing changes

  • hg view
  • hg log
  • hg annotate filename [REV]
  • hg update [REV]
  • hg serv [starts a web server]
  • Use a web browser to browse changes
slide-24
SLIDE 24

Mercurial at MCS

  • MCS Linux boxes has mercurial 0.9 installed
  • /mcs/mercurial/project can be used for hosting

repositories for web acces

  • http://hg.mcs.anl.gov/project is the web url.
  • For eg: some of the repositories of the PETSc

project are at http://hg.mcs.anl.gov/petsc