Distributed Version Control with Mercurial

distributed version
control with mercurial
or: how I learned to stop worrying and love the merge

Presented by Ted Naleid

Wednesday, November 4, 2009

overview
robust and mature
“centralized” and “distributed”
advantages over subversion
why svn merging is broken
subversion’s advantages
comparison to git
concepts
basic usage
how to get started


mercurial is robust
and mature


large projects
Python
Mozilla
NetBeans
OpenOfﬁce
OpenSolaris
OpenJDK
Symbian OS
Xen Hypervisor


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

standalone GUIs
windows - TortiseHG
mac - murky
linux - hgk


IDE support
IntelliJ
Eclipse
NetBeans
Visual Studio
TextMate
BBEdit
emacs
vi


continuous integration and
bug tracking
Hudson
Cruise Control
BuildBot
Bamboo
TeamCity
JIRA
Trac
FogBugz/Kiln

+ support in maven and ant


internet hosting
bitbucket
Google Code
SourceForge
kenai (Sun)


Build Server

commit
Remote
update Repo

centralized version
control systems

Build Server

Build
Repo

sh
pu
ll
pu
commit
Alice's Carl's
update Repo Repo

Bob's
Repo

distributed version
control system

Build Server

Build
Repo

sh
pu
ll
pu
commit push
Alice's Carl's
update Repo pull Repo

pu
sh
pu
ll
Bob's
Repo

distributed version
control system

subversion limitations

mercurial strengths

shared
remote repository

owned
local repository


requires active net
connection

always available


slow over-the-wire
access

speedy local access


single point of failure

multiple redundant copies


working with branches
is slow and painful

simple, in-place
branch switching
hg update branch_name


expensive public
branches discourage
experimentation

cheap, easy
branches encourage
experimentation

saving state is
intertwined with releasing

save whenever, push out
when it’s ready


would you use a word
processor that only let you
save at the end of a
paragraph?


litters workspace
with .svn directories

single .hg directory
at project root


time to set up new
repository limits use

instant setup
enables new uses
hg init
hg add
hg commit -m “first commit”


merging is messy,
dangerous and often
avoided

merging is the core
operation so it’s done well


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


subversion strengths

mercurial
limitations

familiar

new ideas require
understanding


very strong
tool support

tool support not
as mature


better choice for lots of
huge binary files

not optimal for
huge binary files


everyone knows where
the canonical repository is

convention defines
where to push/pull
from

checking out part of a
repository is easy

no easy way to get
only part of a
repository

allows empty directories

tracks files, so empty
directories aren’t
saved

subversion is the clear
leader in free
centralized version control

annoying holy war
raging over
hg vs. git

mercurial git


easy local md5 is easy,
revision numbers right?


plugin design with kitchen sink
basic default
functionality design


better slower http
performance over performance, no
http, built-in quick easy built-in
server serverhg serve


works well on windows support
windows, mac, is lacking and
and linux low priority


history is rewriting history
sacred is a badge of
(though you can commit sacrilege with plugins) honor


mercurial concepts


change sets are stored as
nodes in a DAG
(directed acyclic graph)

tip

newest r3
ﬁle system version

r2
time

r1

oldest r0


a change set with no
children is a “head”

r3

r2

r1

r0


change sets have zero, one
or two parents


the root has zero parents
r4

r3

r2

r1

r0


normal commits have
one parent
r4

r3

r2

r1

r0


merges have two parents
r4

r3

r2

r1

r0


branch name is determined
by the first parent
r4 branch: default r4 branch: release_1.x

r3 branch: release_1.x r3 branch: release_1.x

r2 branch: default r2 branch: default

r1 r1

r0 r0

ﬁrst parent is r2 ﬁrst 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 log
hg diff <-> svn diff
hg cat <-> svn cat

familiar basic hg

hg
blame

add
<->

<->
svn

svn
blame

add
commands hg
hg
hg
remove
rename
update
<->
<->
<->
svn
svn
svn
remove
rename
update
hg resolve <-> svn resolve
hg commit <-> svn commit
hg merge <-> svn merge


hg init
hg add
hg commit -m “project start”

create a new r0 “project start”

repository


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

commit changes
to your r1 “created domain”

local repository r0 “project start”


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

commit changes
to your r2 “updated user”

local repository r1 “created domain”

r0 “project start”


hg update -r 1

switch your file
system to a r2 “updated user”

different revision r1 “created domain”



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

“fix role”
r3
branch: release_1.x

create a branch r2
“updated user”
branch: default

“created domain”
r1
branch: default

“project start”
r0
branch: default


hg update default

“fix role”
r3
branch: release_1.x

merge changes r2
“updated user”
branch: default

from a branch r1
“created domain”
branch: default

“project start”
r0
branch: default


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

r4 “merged branch”

“fix role”
r3
branch: release_1.x

merge changes r2 “updated user”

from a branch r1 “created domain”



hg clone http://path.to.repo

get an existing b b

repository a a

remote local


hg pull

get the latest c

changes from b b

another
repository a

remote
a

local


hg pull

pull adds c c

changes but b b

doesn’t modify
file system a

remote
a

local


hg update

update your c c

working directory b b

with the changes a a

remote local


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


hg pull

we added c to b d c

b b

they added d to b a a

remote local


hg pull

d

d c

pulling in d gives b b

us a new head a a

remote local


hg update
# abort, crosses branches

d

when we try to d c

update to the tip, b b

hg says you need
to merge a

remote
a

local


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

e

d

d c

merge the b b

changes together
a a

remote local

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


hg push

e

d

d c

push changes b b

back out
a a

remote local


hg push

e e

d d

c c

push changes b b

back out
a a

remote local


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!


links
mercurial wiki/download
http://mercurial.selenic.com

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

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

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

ACM article on DVCS
http://preview.tinyurl.com/qezmta


Questions?


Distributed Version Control with Mercurial

Recomendados

Recomendados

Mais conteúdo relacionado

Último

Último (20)

Destaque

Destaque (20)

Distributed Version Control with Mercurial