True Git: The Great Migration

  • In 2011, Atlassian moved their teams from SVN to Git
  • SCM (SVN/Git) use by year across atlassian customers (%, actual and surveyed):
    • 2011: 78/20
    • 2013 (projected): 68/41
    • 2013: 70/49
    • 2015 (projected): 55/68
  • Why git?
    • Branching
      • Branching is fast, cheap and simple
      • Branching is a first class concept within git
      • Value of good branching/merging is that it is the foundation for new workflows
    • Speed. It’s really really fast.
      • git log on confluence - 2 seconds
      • svn log on confluence - 9 minutes
      • Speed leads to innovation
      • git bisect lets you find a particular commit / range of commits, then presents commits to you and asks “is this good or bad?” until you find what you’re looking for.
      • Fast graph traversal, fast checkout
      • Speed enables entirely new features (e.g. pickaxe to find the history of a specific string)
      • Speed improves basic featues
    • Local commits
      • Create and Share. Choose when to publish.
      • Gives flexibility in workfows… This means there is no “should have”
  • Git does what you are doing today, only better
    • SVN has a very narrow way of how you work.
      • You commit to the trunk
      • Branching is often too painuful
    • Git is a superset of what is possible in SVN plus new ways of collaborating, new branching workflows, etc.
  • Stash
    • Release branch for every version released to customers.
    • Master is always the next version to be released
    • To fix a bug, they go back to the oldest version on which they want to fix it.
    • They create a pull request, discuss, and merge up.
    • In stash 2.8 they built a feature to do this automatically – trickle merge.
  • Paradigm Shift - So you’ve decided to migrate!
    • Inception
      • Is git suitable?
        • One disadvantage is that you are storing an entire repo on your machine. This could be huge!
      • Test the conversion
        • Size
        • How does it feel?
      • Identify the repositories that need to be converted
        • e.g. they only migrated the pieces that needed to be moved
      • Identify the tools that will need to be updated along the way
        • CI
        • Issue tracking
        • IDE
        • Scripts/build tools
        • Deployment tools
        • etc.
      • Create a migration plan
    • Adoption
      • You need to answer: “What’s in it for me?”
      • Make sure tooling is ready and can be used by everyone
      • Identify the git champions - they will be thrilled to help!
      • Don’t expect to win everyone over immediately
      • Teach and Communicate!
    • Conversion
      • Go here: bit.ly/go-dvcs
      • git-svn tool used - this is a git client for svn repositories
        • THIS IS NOT A PRODUCTION TOOL
        • This is for advanced git users
      • Preparation
        • Map SVN users names to git identies (matt = Matt Shelton matt.shelton@nuance.com)
        • Identify the SVN repository layout
      • Conversion process
        • git svn clone –authors-file=<> –trunk=/trunk –tags=/tags –branches=/branches
          • THIS TAKES A LONG TIME. The jira project took 3 days!!
        • After initial clone, you need to git svn fetch to sync changes
        • Ends with you having a full git repository on your local machin
      • Infrastructure first!
        • Minimizes downtime
        • set up a git repos that was read-only from SVN
        • Set up the tooling one by one
        • job to sync the git repository every minute from SVN, so devs are not affected by this
      • Final Cleanup
        • cleanup branches
        • remove unused files
        • create git tags
        • remove commit metadata
        • These are DESTRUCTIVE changes - but remember you can try locally
      • After this, everybody uses git. SVN becomes read-only for legacy / leftover tools
    • Other Tools
      • SubGit - works pretty well for simpler cases, not so much for long/rich history in some projcts
  • That’s it... or is it?
    • Collaboration Model?
    • Branching Model?
    • From SVN-like (git cherry-pick) to git branch (git merge)
      • cherry picking loses git’s ability to track changes properly
    • Forks can be very useful!
      • Atlassian has ship-it days, and these can be fairly volatile
      • You can accept changes from outside of the core team
  • Conclusion
    • Huge push towards git, and not just among Atlassian’s customers
    • “svn is being threatened by git for the de facto tool in the scm space”
Oct 2nd, 2013
atlassian, git, notes, summit 2013

Comments