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.

Make It Cooler: Using Decentralized Version Control

7,060 views

Published on

A commonly used version control system in the ColdFusion community is Subversion -- a centralized system that relies on being connected to a central server. The next generation version control systems are “decentralized”, in that version control tasks do not rely on a central server.

Decentralized version control systems are more efficient and offer a more practical way of software development.

In this session, Indy takes you through the considerations in moving from Subversion to Git, a decentralized version control system. You also get to understand the pros and cons of each and hear of the practical experience of migrating projects to decentralized version control.

Version control is often used in conjunction with a testing framework and continuous integration. To complete the picture, Indy walks you through how to integrate Git with a testing framework, MXUnit, and a continuous integration server, Hudson.

Published in: Technology

Make It Cooler: Using Decentralized Version Control

  1. 1. Make it Cooler With Decentralized Version Control Indy Nagpal Straker Software
  2. 2. A bit about me • CTO, Straker Software, New Zealand • Lots of CF and Flex experience • In love with Groovy • Tackling challenges of creating cloud-based software • nagpals.com/blog
  3. 3. Once upon a time, in a galaxy not too far away... There was CVS
  4. 4. And it was a little... well... painful
  5. 5. Subversion made it a little easier
  6. 6. Both are centralized version control systems
  7. 7. Central Server Network in between Clients
  8. 8. http://tinyurl.com/dcvs-explained
  9. 9. A little history • Emerged in 1970s – Yes, that’s about 40 years back • That was the time of – weak clients – grunty mainframes • Centralized teams
  10. 10. Centralized Version Control • Simpler • Works nicely for – backup – undo – synchronization • “Everyone in my team knows how to use it”
  11. 11. So what’s the problem? • Reliance on being connected • Single point of failure • Branching and merging -- a big pain • Growing projects • Diffused teams
  12. 12. Enter...
  13. 13. Decentralized Version Control Systems
  14. 14. Not too long a ago on a planet called Earth Lived a nerd called Linus Torvalds And then there was Linux and Git
  15. 15. Other DVCS Systems Mercurial Bazaar
  16. 16. Main repository Multiple clients clone the repository, including all history Commit changes locally Push to main repository
  17. 17. http://tinyurl.com/dcvs-explained
  18. 18. Decentralized Version Control • Relatively recent innovation • Focus on sharing changes • Recording changes and Applying changes are separated • Fast • Efficient
  19. 19. Decentralized Version Control • Works offline • Branching is cheap • Merging a pleasure • Support for non-linear development • Distributed development
  20. 20. Considerations in switching from Centralized to Decentralized
  21. 21. IDE Support • git-gui, egit (Eclipse), gitx (Mac) • Command-line works very well • Configurable to work with other diff-ing/ merging and editing utilities • Nothing as simple as TortoiseSVN
  22. 22. Repository Hosting Infrastructure • Third party hosting works well – Unfuddle, Assembla – repo.or.cz, github • Host own server • *nix friendly, but have Windows ports
  23. 23. Learning Curve • There is one! And it is a little steep • Getting everyone to change development practice is a biggie • Need a champion who doubles up as trainer • If business finds reason, development teams have limited choice
  24. 24. Existing Repos • Size of repositories • Most DVCS can import SVN repos, including history • Process of migration needs to be planned and implemented
  25. 25. Integration with Third-party Tools • Code repos are tied to other systems: – Bug Tracking – Continuous Integration Systems – Code Review Systems • Switching requires updates to those processes • Do-able
  26. 26. Eternal Truth #1 The longer you use a system, the harder it is to switch
  27. 27. Eternal Truth #2 Inertia does not help
  28. 28. Eternal Truth #3 Lack of a business case does not help either
  29. 29. Eternal Truth #4 Change is the only constant
  30. 30. So where does that leave us?
  31. 31. Choose Git • Seems to have more legs than others • A little more difficult to grasp and work with • But once you’ve got your head around it, and worked with it for a while, it is easy
  32. 32. git-svn • Very useful feature • Checkout a SVN repo as a Git repo • Work with locally as a Git repo • Branch/merge locally as much as you like • Commit locally, and then push to SVN repo
  33. 33. A few other useful things • Only one .git folder, not a zillion .svn folders • Create local repos for things you normally wouldn’t • Efficiency – 1.5 GB svn repo = 700 MB git repo • Speed – Of local commits and pull/push from main repo
  34. 34. Resources • Git – git-scm.com • Peepcode – peepcode.com/products/git • Pragmatic Programmers – pragprog.com/titles/tsgit/
  35. 35. One Last Truth Automation is the key
  36. 36. On Automation and Developers Given a choice between spending an hour doing a task manually, or spending three hours writing a program to do it automatically... a geek will write the program, every single time. And, if not given the choice, if explicitly ordered to do the job manually, we'll disobey and write the program anyway. Catherine Devlin (http://tinyurl.com/devautomation)
  37. 37. Hook DVCS up with Testing and CI
  38. 38. Unit Testing • MXUnit works well • mxunit.org/ • Writing testable code -- key to automation • Retro-fitting tests does not work • Have to write tests before writing code • Makes the code more robust
  39. 39. What is testable code • Marc Esher’s presentation on Testable Code: – Extracted – Abstracted – Injected
  40. 40. Git with Unit Testing • Agnostic • Key issues are: – Where do you store tests – How do you run them
  41. 41. Continuous Integration • Hudson works extremely well • https://hudson.dev.java.net/
  42. 42. Setting up CI Workflow • Set up project • Ping Git repo / Implement callback • Checkout if new changes • Call MXUnit Unit Ant Task to run tests • Publish report • Notify
  43. 43. Thank you! indy@strakersoftware.com strakersoftware.com nagpals.com/blog

×