mercurial dvcs presentation to devjam 11/4/2009

distributed version control with mercurial

or: how I learned to stop worrying and love the merge

Presented by Ted Naleid

Wednesday, November 4, 2009

robust and mature“centralized” and “distributed”advantages over subversionwhy svn merging is brokensubversion’s advantagescomparison to gitconceptsbasic usagehow to get started

overview


mercurial is robust and mature


large projectsPythonMozilla

NetBeansOpenOfficeOpenSolarisOpenJDK

Symbian OSXen Hypervisor


cross platform support great command line on win/mac/linux

standalone GUIs windows - TortiseHG

mac - murkylinux - hgk


IDE supportIntelliJEclipse

NetBeansVisual Studio

TextMateBBEditemacs

vi


continuous integration and bug tracking

HudsonCruise Control

BuildBotBambooTeamCity

JIRATrac

FogBugz/Kiln

+ support in maven and ant


internet hosting

bitbucketGoogle CodeSourceForgekenai (Sun)


centralized version control systems

Remote Repoupdate

commit

Build Server


distributed version control system

Alice'sRepo

Build Repo

Carl's Repo

Build Server

Bob's Repo

commit

update

push

pull


distributed version control system

Alice'sRepo

Build Repo

Carl's Repo

Build Server

Bob's Repo

commit

update

push

pull

push

pullpushpull


mercurial strengths

subversion limitations


owned local repository

shared remote repository


always available

requires active net connection


speedy local access

slow over-the-wire access


multiple redundant copies

single point of failure


simple, in-place branch switching

hg update branch_name

working with branches is slow and painful


cheap, easy branches encourage

experimentation

expensive public branches discourage

experimentation


save whenever, push out when it’s ready

saving state is intertwined with releasing


would you use a word processor that only let you

save at the end of a paragraph?


single .hg directory at project root

litters workspace with .svn directories


instant setup enables new uses

hg inithg add

hg commit -m “first commit”

time to set up new repository limits use


merging is the core operation so it’s done well

merging is messy, dangerous and often

avoided


why is subversion merging so broken

and scary?


#1

when there are conflicts, you’re forced to merge into an unsaved working copy


#2

when there are no conflicts, you aren’t forced to merge

this is a bug, not a feature


in mercurial, you commit before pulling new code

only fully formed changes get pushed out

history is always preserved


merging is a common, trivial operation

a merge occurs every time you pull down new code


mercurial limitations

subversion strengths


new ideas require understanding

familiar


tool support not as mature

very strong tool support


not optimal forhuge binary files

better choice for lots ofhuge binary files


convention defineswhere to push/pull

from

everyone knows where the canonical repository is


no easy way to get only part of a

repository

checking out part of a repository is easy


tracks files, so empty directories aren’t

saved

allows empty directories


annoying holy war raging over

hg vs. git

subversion is the clear leader in free

centralized version control


mercurial git


easy local revision numbers

md5 is easy, right?


plugin design with basic default functionality

kitchen sink design


better performance over http, built-in quick

serverhg serve

slower http performance, no

easy built-in server


works well on windows, mac,

and linux

windows support is lacking and

low priority


history is sacred

(though you can commit sacrilege with plugins)

rewriting history is a badge of

honor


mercurial concepts


change sets are stored as nodes in a DAG

(directed acyclic graph)

r0

r2

r1

r3newest

oldest

time

tip

file system version


a change set with no children is a “head”

r0

r2

r1

r3


change sets have zero, one or two parents


the root has zero parents

r0

r2

r1

r3

r4


normal commits have one parent

r0

r2

r1

r3

r4


merges have two parents

r0

r2

r1

r3

r4


branch name is determined by the first parent

r0

r2

r1

r3

r4

branch: default

branch: release_1.x

branch: default

r0

r2

r1

r4

branch: default

branch: release_1.x

branch: release_1.x

r3

first parent is r2 first parent is r3


history is immutable


merging only happens in your local repository


that’s it!


mercurial usage


hg status <-> svn status hg log <-> svn loghg diff <-> svn diffhg cat <-> svn cathg blame <-> svn blame

hg add <-> svn addhg remove <-> svn removehg rename <-> svn renamehg update <-> svn updatehg resolve <-> svn resolvehg commit <-> svn commithg merge <-> svn merge

familiar basic commands


hg inithg addhg commit -m “project start”

create a newrepository

r0 “project start”


commit changes to your

local repository

<changes ...>hg commit -m “created domain”


“created domain”r1


commit changes to your

local repository

<more changes...>hg commit -m “updated user”



“updated user”r2


switch your file system to a

different revision

hg update -r 1


“created domain”

“updated user”

r1

r2


create a branch

hg branch release_1.0.x<changes...>hg commit -m “fix role”

r0“project start”branch: default

“updated user”branch: default

r2

“created domain”branch: default

r1

“fix role”branch: release_1.x

r3


merge changes from a branch

hg update default

r0

r2

r1


r3

“project start”branch: default

“updated user”branch: default

“created domain”branch: default


merge changes from a branch

hg merge release_1.x<resolve any conflicts>hg commit -m “merged branch”


“updated user”r2



r3

r4 “merged branch”


get an existingrepository

hg clone http://path.to.repo

a

b

a

b

remote local


http://path.to.repo

http://path.to.repo

get the latest changes from

another repository

hg pull

a

b

c

a

b

remote local


pull adds changes but

doesn’t modify file system

hg pull

a

b

c

a

b

c

remote local


update your working directory with the changes

hg update

remote local

a

b

c

a

b

c


what if you’ve already made a change in your repository?


we added c to b

they added d to b

hg pull

remote local

a

b

d

a

b

c


pulling in d gives us a new head

hg pull

remote local

a

b

d

a

c

b

d


when we try to update to the tip, hg says you need

to merge

hg update # abort, crosses branches

remote local

a

b

d

a

c

b

d


merge the changes together

hg merge<resolve any conflicts>hg commit -m “merge done”

hg fetch does all this in one command(pull, update, merge, commit) use that instead

remote local

a

b

d

a

c

b

d

e


push changes back out

hg push

remote local

a

c

b

d

e

a

b

d


push changes back out

hg push

remote local

a

c

b

d

e

a

c

b

d

e


how to get started with mercurial


watch the peepcode screencast

$9, cheap!


read the book

free online!


install it


start small


convert your existing repository


commit and share often


install and learn to use a 3-way merge tool


profit!


linksmercurial wiki/downloadhttp://mercurial.selenic.com

O’Reilly’s Mercurial - The Definitive Guidehttp://hgbook.red-bean.com/ (free!)

peepcode intro screencast ($9)http://peepcode.com/products/meet-mercurial

mercurial branching infohttp://stevelosh.com/blog/entry/2009/8/30/a-guide-to-branching-in-mercurial/

ACM article on DVCShttp://preview.tinyurl.com/qezmta


http://bitbucket.org/tednaleid/grails-test-data/wiki/Home








http://preview.tinyurl.com/qezmta

http://preview.tinyurl.com/qezmta

Questions?


mercurial dvcs presentation to devjam 11/4/2009

Technology