Published on

A Distributed Version Control System

Dmitriy Iassenev
GSC Game World

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


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