Distributed version control (Specifically, Mercurial) 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 git 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 ● Trac 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 .