Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

A Distributed Version Control System

Dmitriy Iassenev
GSC Game World

Published in: Technology
  • Login to see the comments

  • Be the first to like this


  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 />