Mercurial is part of a modern way of thinking about source control where the system is distributed among developers compared to the client server model of things like SubVersion. This presentation covers what that means to developers.

1. Mercurial robertmaclean www.sadev.co.za ∞ @rmaclean ∞ robert@sadev.co.za

2. Mercurial April 2005 Created for Linux Kernel DVCS Distributed Version Control System It’s just source control, so what you know is still relevant

3. Client/Server Source Control Central management All code, all history, all settings Just working set Good & established tool (build, WI) integration SVN Merge has only working set knowledge LOCKS?! ARRGGHH! Connection to server needed .svn pollution Cannot share between people without the server Server is unaware of renaming

4. DVCS Everyone has full repo Tool integration is still growing Merge has full knowledge No locking hg hg hg hg hg hg Can work disconnected Single .hg directory Aware of renaming Easy to share between people

5. So it is perfect? Some management (users) issues Can be solved on the transport Maturity needed No reason not to check-in ALL the time Backups? Can’t delete branches Performance issues Can’t pull a working set Workflows need to change

7. Run testing, deployment builds

8. What happens if you go dark?

9. What about security?

10. How do I add or remove users?

11. Where is the backup that we will use when the building burns down?hg hg hg hg hg hg

12. The Blessed Repo Workflow Build server runs against blessed repo WI against this hg hg hg hg hg hg hg Backup this Central Management Here Familiar model

13. The Hybrid Blessed Repo Workflow Mercurial to SVN Bridge hg hg hg hg hg hg SVN

14. Network of Trust Workflow King hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg Penguins Disk Graphics Networks Lieutenants Unwashed Masses

15. Corporate Network of Trust Workflow Seniors hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg Intermediates Juniors

16. Deployment Team Workflow Deploy Can run own workflows Can have own build and ship quality gates hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg hg Pre-Prod Can have own branching strategy Development

17. Proven Practises Alignment? Branching Plan your branching Own the merge Look after branches Repo Don’t break the build Separate your repo Don’t forget to shelve Use labels Tech Try concurrent access Don’t be afraid of branching concepts Auto merge for checkout only Management Don’t use the audit trail for blame Useful & meaningful check in messages You Be light and quick with checkouts Keep up to date Don’t check in unneeded binaries Working folders should be disposable Use undo/revert sparingly

18. Commands (51) Add, AddRemove, Remove [rm] Annotate [Blame] Archive Backout Bisect Bookmarks Branch & Branches Bundle & Unbundle Cat Clone Commit [ci] Copy [cp] & Rename [move, mv] Diff Export & Import [patch] Forget Grep Heads Help Identify [id] Incoming [in] & Outgoing [out] Init Locate Log [history] Manifest Merge & Resolve Parents Path Pull & Push Recover Revert Rollback Root Serve ShowConfig [debugconfig] Status [st] Summary [sum] Tag & Tags Tip Update [up, checkout, co] Verify Version

19. Command Cheat Sheet

20. Other DVCS Options Git Linus Torvalds Linux Kernal Requires packing maintenance Unfriendly version numbers FAST Linux & Mac Different patching ideology No working set issue Can delete branches Bazaar Canonicial Ubuntu Slow Closer to SVN Monotone, Darcs, Plastic, SVK, Codeville, GNU arch, Bitkeeper

21. Questions?