Distributed

(Specifically, )

Overview

● Explain some of the basics of Mercurial ● Describe the ways in which Mercurial is an improvement to SVN

● Not saying SVN can’t do any of these ● Just that they are easier in a DVCS ● Most of this will also apply to

Basics (1)

● A simple model bpc4/ bindings/ ● Command-line: hg build/ demos/ .hg/ ● documentation/ Concepts engine/ qa/ ● Repository – .hg directory in root ● Working copy ~/testproject$ hg init ● ~/testproject$ ls -a Init . .. .hg ● Clone ~/testproject2$ hg clone ../testproject

Basics (2)

● Concepts

● Changesets ● Directed acyclic graph ● Tip ● Branch ● Head ● Update ● Ids – SHA-1 – numbers (local)

Distribution

● Concepts +

● Push = ● Pull ● Through these, repositories are combined ● When this causes a branch, a merge is needed ● Merges are also distributed

Sharing changes

● Built-in hg serve (HTTP) ● File system share ● Export / import ● Bundle / unbundle ● Email ● SSH ● Shared repository space on webserver ● Hosted services like Bitbucket, Google Code

● Easily upload a copy with hg push Typical project setup

● Central repository on HTTP projects server ● Typical workflows:

● Give everyone push access ● Have a tree ‘master’ who pulls changes from everyone if approved ● These can be mixed, e.g.:

● Give senior devs push access ● Pull from new/junior developers after review

Additional possible workflows

● Separated repositories for different teams

● Documentation, localisation ● Code review

● Easy to get quick feedback through hg serve ● Share changes among each other to test before pushing to central repo

Easier merging — updates

● No need to update before you check in

● Can checkpoint your code before merging ● Solve conflicts separately, not mixed with changes ● SVN: adds markers for conflicting changes

● You’re blocked until you fix it ● No way to revert to previous state ● Result: users will not update until they’re done ● If a merge fails in Mercurial, you can ignore it

● Will not disrupt your workflow

● You can integrate early without risk Easier merging — branches

● Less merge conflicts on long-lived branches

● Mercurial does better tracking ● More solid underlying model and merge strategy ● Better supports intermediate merging – See updates – More up-to-date branch means less conflicts ● Better supports small commits ● SVN: blob merge, not smart

● It has repository and merge info, but doesn’t use

Better repository consistency

● You can not update part of the source tree ● Merging is always required ● SVN: If you are not up-to-date, committing changes will still go through when there are no conflicts. ● This means that at that point the repository is in a state that has never even been tested or reviewed by a human.

Easier branching

● SVN: discourages branching

● Technically no real obstacles, however – Slow, complicated, public, and the merging is broken – People don’t tend to do it. The ‘human factor’. ● Mercurial branching is quick and simple

● In fact, your local repository is already a branch – Which you can put aside if you want to work on something else ● Easily make local testing branches

● Still able to benefit from version control

Better support for your workflow

● Small, incremental commits are good!

● ‘Checkpoints’ for your code ● Easy to review ● SVN: discourages them

● Incremental commits need to be quick ● But not thoroughly testing may break the tree ● Mercurial commits are local

● Incremental commits are easily made ● If it did not work properly, you block no-one

Local repository benefits (1)

● Complete repository is stored locally

● Only need to be connected to push to central repo ● This mean you are not blocked, nor filing high- priority tickets to IT, in the following cases:

● Internet downtime ● SVN downtime – Malconfigured permissions, hard drive failure, etc. ● The above are all actual cases that have occurred with relative frequency the past years. Often blocking tens of developers.

Local repository benefits (2)

● Additionally, a local repo is convenient for:

● Ziggo intranet / extranet situations ● Usage of the Amsterdam infrastructure by the US – Because it does not perform badly ● Changes that accidentally break the tree – As long as you didn’t push yet, you can go home without blocking your fellow developers ● Accepting changes from developers (e.g. from different teams, or PS) that don’t have push access ● Observing the effects of changes (e.g. merges) before sharing them.

Local repository benefits (3)

● Redundancy

● As all developers have a local copy of the complete repository, there is no single point of failure in the infrastructure, and backups aplenty ● After a catastrophic failure, quickly getting back to a working setup is simple and not blocking the developers

Correcting mistakes

● Rollback

● Rolls back last transaction ● Safe, convenient! – Correcting commit message, missing files, etc. ● Revert ● History editing

● Not recommended for non-local changes – Can be used on shared repositories in emergency cases ● Rebase

● Mercurial queues (‘mq’) / histedit / convert Cherry-picking

● Transplant ● Better: Daggy fixes

● Fix immediately after the change that introduced it ● Then merge forward on any branch you want it

Repository sizes

● Converted BPC4

● 4691 files, ~25000 changesets ● Repository size: 77,9 MB ● Working copy size: 74,6 MB (33,6 MB zipped) ● Converted cobrowse

● 1703 files, ~1600 changesets ● Repository size: 79,6 MB ● Working copy size: 39,3 MB (24,0 MB zipped) – (was 87,2 MB 400 revisions ago!)

Tool support

● TortoiseHg

● Commit hunk selection ● HgEclipse ● Maven ● JIRA plugin, FishEye integration coming ● Fogcreek Kiln

● Mercurial repo manager + code review tool ● ReviewBoard

● plugin Weaknesses

● Large binary files (>10 MB)

● Don’t do it! – Repository size increases equally – No delta compression possible ● Solutions: – Maven artifactories – Bfiles – SVN subrepository (!)

Migration from SVN

● Convert extension

● Built-in ● Hgsubversion

● Designed for working with Mercurial on top of SVN ● Has ability to push changes back to SVN – Offers a path back to SVN if desired – Will not preserve usernames or timestamps though

For the SVN addicts

● If you really can’t let go of SVN… ● SVN style workflow

● hg pull -u ● hg commit;hg push – can make alias for that :) ● (Don’t, though…)

Links

● http://mercurial.selenic.com/ ● http://hgbook.red-bean.com/ ● http://hginit.com/ ● http://hgtip.com/ ● http://bitbucket.org/

Mindshare

● Mozilla ● Python ● OpenJDK (Java 7) ● OpenOffice.org ● NetBeans