Download - Mercurial
Mercurial
A Distributed Version Control System
Dmitriy IassenevGSC Game World
2011
Why Mercurial?
• Pros– It has rich functionality– It is easy to customize• If you like Python
– It scales good• Big files need to be handled carefully
– It has good GUI client – TortoiseHG– It is easy to learn• Non-progammers could have problems with it
Why Mercurial?
• Cons– Every user has the whole repository• User access rights problems – use subrepositories?• Every user should have enough HDD space
Mercurial vs Subversion
• Pros– Simpler for non-programmers– Even better GUI client – TortoiseSVN (at the time
we choose)– Handle big files well without any additional effort– Need less space on HDD– Mixed revisions working copy– Exclusive file lock
Mercurial vs Subversion
• Cons– Centralized VCS
• No local commits• No inter-repository commands
– Slower on most operations– Complicated and restrictive merge and branch
functionality– In some use cases need even more space on HDD– .svn folders– Impossible to setup ignore filter for future folders– Easier to loose your changes
Mercurial vs Git
• Pros– Even more rich functionality– Faster on Linux
Mercurial vs Git
• Cons– Worse performance on Windows (2009 year
measurements)– You should “repack” your local repository to
prevent performance degradation– No good free GUI client for Windows at the time
we choose – TortoiseGit?– It is known to be more complicated for both
programmers and non-programmers
How does Mercurial work?
• Local Repository and Working Copy– commit– update– merge– rebase
Local repository and Working Copy
• Merge1
2 3
Local repository and Working Copy
• Rebase1
2
Inter-repository communication
• clone• pull– After pull commands• Update• Fetch = update + merge + commit• Rebase
• push– push after commit option
• serve
Tags and Branches
• Tags– Merge tags - .hgtags
• Branches– Repository clones– Markers– Named branches– Anonymous branches (several heads in a branch)– Branch hierarchy doesn’t depend on folders
structure (unlike Subversion)
Under the hood
• Deltas even for binaries• Atomic transactions – only append to revlog• Fast retrieval – snapshots• File and folder renames– Avoid case sensitive renames on case insensitive FSs
• Compression: deflate and bzip2• Concurrent access – lockless reading• Minimizing disk seeks• Hard links for cloning repositories locally
Recovering from errors
• Revert• Rollback– Undo the last commit– Undo erroneous pull
• Backout• Recovering from erroneous merge
Recovering from errors
• Rollback1
2
Recovering from errors
• Backout1
2
Recovering from erroneous merge1 2
3 4
Hooks
• changegroup – we use it to detect when someone pushed to repository
• precommit – we use it to prevent case folding collisions
Extensions
• Modified Bigfiles• Fetch• Rebase• Transplant• Mercurial Queues (for Strip)
How we use Mercurial
• Multiplatform engine for video game and game itself (Win32, Win64, Xbox360, PS3)
• C++ for engine and game, C# for tools (.NET + WPF)• Team: 11 programmers + 13 designers (up to 40 designers in
a production stage)• ~467k lines of code ~= 15Mb• ~3.5M lines of code from various SDK and third party
libraries which we build ~= 132Mb• Working Copy: ~33.6k files and folders ~= 16.8Gb• Local Repository (~0.4Gb) => 17.2Gb per user• Full repository ~= 135Gb
Continuous Integration Workflow
• 2 Central repositories + Build station– Programmers repository– Build station repository– Designers repository– We plan to use Central repository for Testers
Continuous Integration Workflow
• on push to Programmers– pull Build station from Programmers– build binaries for all 16 projects configurations– run tests– commit to Build station repository on success or report
failure otherwise– pull from Designers– push to Designers
• on push to Designers– pull Programmers from Designers
Merge tool we use - Perforce p4merge
Questions?
• Feel free to email me [email protected]• Online resources:– “Mercurial: The Definitive Guide” by Bryan
O'Sullivan - http://hgbook.red-bean.com/– Joel Spolsky Tutorial on Mercurial -
http://hginit.com/