Distributed Version Control

Distributed Version Control

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 .

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    25 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us