Sessions‎ > ‎2011 Sessions‎ > ‎

Using DVCS: Risk, Rewards, and the Cool Kids

·         DVCS – Distributed Version Control System

·         Some popular DVCSs (in no particular order):

o   Darcs

o   Bazaar

o   Git

o   Mercurial

 

·         Barry Hawkins: “There is way more people using a DVCS than there should be.”

o   Many people are using a DVCS simply because it’s the cool thing to do right now, but many of them do not truly understand how to properly use a DVCS.

·         By necessity DVCSs support powerful merging.

o   Merging is a killer application of DVCS.

o   If merging didn’t work well, then it would be difficult to pull and push changes between repositories.

·         Question: How does DVCS fit into a corporate environment?

·         Centralized version control is “safer”. In most DVCSs, it is easy to shoot your own foot off (particularly with Git).

·         DVCS reduces the risk of pushing large changes.

o   When using a DVCS, developers tend to commit often and a lot.

o   When developers push, they push a whole batch of commits (change-sets).

·         DVCS enabled distributed development

o   Each developer has a complete copy of the repository, thus, working offline is possible.

·         Pulling changes from one repository to another is all about trust.

o   This is particularly true in public DVCS environments such as Github.

o   DVCS gives you the choice about who you trust.

A Metaphor for Version Control

·         Version control systems are the hydrolic systems of software development.

o   Developers exert pressure on the system by making and committing changes.

o   The version control system is responsible for managing the pressure.

·         The “friction points” in a DVCS is different from the friction points in a CVCS

o   DVCS spreds out the friction points, thus reducing the chances of an individual developer running into problems.

o   VCS centralizes the friction points, increasing the chances of an individual developer running into a problem.

Shooting yourself with DVCS

·         Developers often develop a false sense of security.

o   Just because DVCSs tend to be good at merging and branching doesn’t mean developers should use it, or should try to use it without understanding how DVCS works, or the full implications of using a DVCS instead of a CVCS (Central Version Control System).

·         Partially understanding how DVCS works is a great way to get oneself into trouble.

o   Many developers struggle to understand DVCSs because it is fundamentally different from traditional CVCSs.

Who should use DVCS?

·         Just as with Agile, adapting a DVCS requires the right culture.

o   A culture open and ready to change

o   A distributed culture

o   A culture where self-discipline thrives

o   A culture where experimentation is encouraged

·         Using a DVCS requires a stronger process than using a CVCS.

Adapting a DVCS

·         Setup Test Repositories

o   Allows developers to experiment and play with the DVCS in a “safe” environment.

o   Most DVCS make setting up test repositories very easy.

·         Start with a model which is similar to a CVCS:

o   One master repository which everyone pushes to.

·         Most DVCS have tools for synchronizing with the popular CVCS (particularly Subversion)

o   Example: git-svn

o   The Pragmatic Bookshelf contains a whole series on version control. Anyone thinking about moving to Git should read Pragmatic Version Control using Git.

·         If you find a lot of developers frequently working in the same file, then your system design might have a problem.

o   The system may need to be decomposed or broken into smaller modules.

·         Isolate work, not people.

o   DVCS makes isolating work easy:

§  Create a new clone

§  Create a branch in your local repo

§  Share branches with other developers working on the same project

o   Isolating people prevents collaboration and innovation.

Git vs Mercurial

·         Many people find Git hard to learn as its terminology is vastly different from other version control systems (more on this later).

·         Mercurial uses terminology more consistent with traditional version control systems.

·         Mercurial is immutable à Editing history is not allowed.

·         Git is mutable à It’s easy to edit history before it’s pushed.

o   Git’s ability to edit history is one of the features which makes git seductive.

o   Git users like to re-organize commits to help “tell a story” about how the code evolved.

·         In Mercurial, tagging is a separate commit.

o   Tags are versioned, just like everything else.

o   Reverting a commit can reverse what commit a tag points to

·         In Git, tags are simply aliases to a particular commit.

·         Git is well supported on Linux, but is poorly supported on Windows

o   Tortoise Git is making some progress in becoming a more stable option.

·         Mercurial is well supported on Linux and Windows

o   Tortoise Hg is mature, stable, and very easy to use.

·         Eclipse Support

o   Git Eclipse Plugin is still evolving

§  Since it’s adaption into the Eclipse Foundation, development has accelerated.

o   Mercurial Eclipse Plugin is mature and well supported.

Different Terminology for the Same Concepts

·         Every DVCS uses slightly different terminology to refer to the same set of concepts.

o   Makes comparing DVCSs difficult and frustrating.

o   Makes learning a new DVCS difficult

·         The developer community would benefit greatly from a “DVCS Terms and Concepts Rosetta Stone”, which would show the concepts, and what terminology each DVCS uses to refer to each concept.

Using github to host company code

·         Github is an online Git hosting website

o   Easy to create repositories

o   Easy to share code between repositories

o   Easy to fork a repository

o   Free for public use

o   Private repositories require a modest fee.

·         Painful user administration

o   No Groups

o   Okay for open source projects, but a real problem for private, commercial projects.

·         Makes it far too easy to leak code to the public

o   Until recently, it was not easy to forcibly delete a public fork of a private project.

·         Tracking forks is easy (so it is easy to find public forks).

·         For private development, it is just as easy to host your own git repositories internally as it is to setup a github project.

o   Thus, using Github for private projects has limited value:

§  Good for teams distributed in multiple locations (doesn’t require the use of a VPN)

Links

·         Darcs

o   http://darcs.net/

·         Bazaar

o   http://bazaar.canonical.com/en/

·         Git

o   http://git-scm.com/

·         Github  (Git Hosting)

o   https://github.com/

·         Mercurial

o   http://mercurial.selenic.com/

·         BitBucket (Mercurial Hosting)

o   https://bitbucket.org/

·         The Pragmatic Bookshelf

o   http://pragprog.com/

·         Book: Pragmatic Version Control using Git

o   http://pragprog.com/titles/tsgit/pragmatic-version-control-using-git

Comments