Intro to Distributed Version Control

transcript

DVCDistributed Version Control

Tech Talk Presented @ CDL 02/24/2010 by Stephanie Collett

Friday, February 26, 2010

This talk is about distributed version control, with some background on version control, and centralized version control.

VCVersion Control

There are several names for the basic idea of software version control.

RCRevision Control

Some call it revision control.

SCMSource Code Management

Source Code Management is another one.

SCSource Control

One I use now and then is Source Control. Though sometimes there is nuanced, often these four are all used synonymously.

Centralized

CSCMCRC

Sometimes there are prefixed with Centralized, referring to the technical architecture of the implementation.

Distributed

DSCMDRC

Distributed refers to the architecture too. But it is all just a type of it is version control.

RCSSystem

Systems is often suffixed to refer to the technical implementations of version control.

http://www.flickr.com/photos/lotterymonkey/115959194/Friday, February 26, 2010

Though some are more common then others, you might see 12 acronyms that mean software version control of one type or another.

Version Control

Though this is about software version control, the idea is not unique to software.

Documents/

Often when people have a monumental change to a document, they save the current one with some suffix like “old” to make sure they can go back if needed. That breaks down fast, but there are other naming conventions used to get around that. If you start collaborating you might have person-specific versions of versions.

business_letter.doc

Documents/

business_letter.doc

business_letter_old.doc

Documents/

business_letter.doc

Documents/

business_letter_02_24_2010.doc

business_letter.doc

Documents/

business_letter_v1.doc

business_letter.doc

Documents/

business_letter_v1.doc

business_letter_v1_cdf.doc

http://www.flickr.com/photos/wokka/2836512221/Friday, February 26, 2010

This can get cluttered very fast.

http://www.flickr.com/photos/pio1976/3330670980/sizes/l/Friday, February 26, 2010

Version control organizes all of those versions, making it easier to work.

for documents there is track changes

for source code there is version control repositories

This is an example of a simple “Hello World” program in a version control workflow. First, create a repository (it can be local or on a server some where). Second, begin committing changes to it.

(Working) Directory

Repository(Working) Directory

Initial CommitFriday, February 26, 2010

RepositoryWorking Directory

Another CommitFriday, February 26, 2010

Third CommitFriday, February 26, 2010

Repository

Add | Modify | Delete

Software usually requires multiple dependent files, so version control can handle multiple files per commit.

Repository

http://www.flickr.com/photos/tanaka/2345575389/sizes/l/Friday, February 26, 2010

It is helpful to think of these commits as snapshots. Although, often version control repositories internally only store changes by commits or employ other ways to reduce size.

Repository

However, no matter how they internally store the changes, checking out a version will give you a snapshot of the code at the time of the commit.

Repository

Checkout B

Repository

Checkout C

Checkout B

Why Version Control?

There are many reasons why version control is helpful for development.

Rollback

Being able to rollback to a previous version is the most useful thing about VC.

http://www.flickr.com/photos/johnjoh/448665548/Friday, February 26, 2010

Make a mistake, no problem. Just rollback to the last version. Make a mistake 11 commits ago. No problem there either. (for supercharged rollback, check out bisecting in Git or Mercurial.)

Development

VC helps support the development workflow as well.

Respository

Let’s start with a simple repository.

http://www.flickr.com/photos/chanc/3178816533/sizes/o/Friday, February 26, 2010

The main line of code is often called the trunk. Sometimes you might not want to pollute your trunk with a really experimental feature you might never release. So you can branch. If you are successful, the branch can be merged later.

Branch

How does that work?

First, computer will try to intelligently merge.

http://www.flickr.com/photos/genewolf/147722422/Friday, February 26, 2010

If there isn’t much overlap between the two sets of code you are merging, than the VC should handle the merge for you.

Conflict!

If not, it will give you a conflict warning.

You figure it out.

Which snippet of code do you want?

A. The snippet from this version

B. The snippet from that version

C. None of the above (I’ll make my own)

Before merging you have to decide what to keep and what to toss. Some merging is so complex, you need to write more code to make the pieces fit.

Release

VC systems often have a simple feature to help with releases.

Commits Tags

Release 1.0

Release 1.1

Tagging is a way to declare certain snapshots as a version. With thousands of commits, nobody wants to remember the “5162f860d29e5a25c354697ee5f8795c28f0bda2” is Release 1.3.

History

The history is one of the most important features, especially for collaboration.

Author

Time/Date

Comment

History usually includes author, time/date, and a comment (often optional). Though some systems require comments, they can’t require useful comments. These are important to other developers, or even the original author a few months later.

Collaborate

Major VC systems allow for collaboration by allowing people to share repositories or commits.

http://www.flickr.com/photos/healfdene/2580099594/Friday, February 26, 2010

Centralized Version Control

Centralized Version control has been around for almost 30 years. CVS and SVN are popular implementations.

One Repository...

Central

Repository

...used by one or more developers

as represented by my favorite Lake Merritt residents

attribution last slideFriday, February 26, 2010

internet/network

Central

Repository

Each one of these developers has access to the repository.

http://www.flickr.com/photos/outerbankscandy/79480040/Friday, February 26, 2010

If there image that sets centralized from distributed version control its the mothership. You can’t do anything without consulting the mothership. All commits, branches, and merges go through the central repository.

Repository

Checkout C

So for this checkout the repository keeps all the versions, and the Duck only gets snapshot C on his local computer.

internet/network

Central

Repository

Central repository is empty

So here’s an example with a empty repository.

internet/network

Central

Repository

Duck commits A

Duck creates some code and commits it. It because commit A.

internet/network

Central

Repository

Everybody else checks out version A

Squirrel and Pidgin download the code from the repository.

internet/network

Central

Repository

Pidgin commits B

Pidgin makes some changes and commits B to the repository.

internet/network

Central

Repository

Squirrel tries to commit version C

Squirrel makes some changes too and tries to commit them.

Conflict!

Doh! Squirrel didn’t have Pidgin’s changes in commit B, so now there is a conflict.

internet/network

Central

Repository

Squirrel merges and commits version C

After a merge, then Squirrel can commit the changes to the central repository.

internet/network

Central

Repository

Duck and Pidgin update to version C

Everybody updates there code from the repository, and they are all on the same page again.

How do you avoid a conflict?

Update frequently

Try to find the conflicts before they get big. If there is one, you’ll get it when you update.

Coordinate

Try not to be working on the same thing at the same time.

internet/network

Central

Repository

Pidgin admins the repository on the server

Another thing about centralized version control is the importance of the administration. A service needs to be running and the admin needs to manage the users. You wouldn’t want just anybody updating your only repository.

Distributed Version Control

With distributed version control EVERYBODY gets there own repository. In fact, many people get more than one.

http://www.flickr.com/photos/philippeleroyer/2202178647/sizes/l/Friday, February 26, 2010

The first thing people tend to ask me when they hear this: “Isn’t that just chaos?”

The short answer.

The short reply.

Repository

Squirrel creates a repository on her local machine

(The most basic way to start out)Friday, February 26, 2010

Here is another example. With DVCS you can start solo. Let’s say Squirrel has a pet project. She can put it in her own DVCS repository on her local machine. Its quite easy.

Commits

Repository

Squirrel begins committing to the local repository

Once she creates the repository she can commit her code changes to it. It is a fully functional repository.

internet/network

Local Repository

Squirrel creates a public repository

Public Repository

Squirrel decides it might be useful to other people, and creates a publicly accessible repository.

internet/network

Public Repository

Local Repository

She pushes changes to the repository

internet/network

Public Repository

Local Repository

Duck decides to use Squirrel’s project

(The other way to start out)Friday, February 26, 2010

internet/network

Public Repository

Local Repository

He clones Squirrel’s public repository

Local Repository

Duck now has the complete version history.

internet/network

Public Repository

Local Repository

Squirrel adds commit “C” to the local repository

Local Repository

Squirrel makes a change and commits it to the local repository.

internet/network

Public Repository

Local Repository

She pushes changes to the public repository

Local Repository

internet/network

Public Repository

Local Repository

Duck pulls changes from Squirrel’s public repository

Local Repository

internet/network

Public Repository

Local Repository

He makes his own commits to his local repository

Local Repository

Duck makes some changes to the code for his own use.

internet/network

Public Repository

Local Repository

But he can’t push his changes to Squirrel’s public repository

Local Repository

He decides they would be useful to others, but will not be able to send them back to Squirrels public repository.

internet/network

Public Repository

Local Repository

Duck creates a public repository

Local Repository

PublicRepository

internet/network

Public Repository

Local Repository

Duck pushes to his public repository

Local Repository

PublicRepository

internet/network

Public Repository

Local Repository

Duck notifies Squirrel of his spiffy changes through email, or whatever

Local Repository

PublicRepository

Hopefully Squirrel has listed her email or how she wants to be contacted for patches.

internet/network

Public Repository

Local Repository

She likes the changes and pulls them

Local Repository

Public Repository

internet/network

Public Repository

Local Repository

She then pushes them to her public repository

Local Repository

PublicRepository

internet/network

Public Repository

Local Repository

And there you have it!

Local Repository

Public Repository

Everybody has the same revisions in their repositories.

A few things to note

What if Squirrel had coded some more changes?

internet/network

Public Repository

Local Repository

Public Repository

XConflict!

internet/network

Public Repository

Local Repository

Public Repository

Squirrel merges the changes to her local repository

What if Squirrel doesn’t like Duck’s changes?

internet/network

Public Repository

Local Repository

She doesn’t need to pull them, ever

Local Repository

PublicRepository

If they are friends or colleagues, VC does not socially moderate the implications of rejection. You are on your own.

But what if they are super cool, and they would be useful to

other users?

internet/network

Public Repository

Local Repository

Nothing stops other users from cloning/pulling

Local Repository

Public Repository

LocalRepository

internet/network

Public Repository

You can pull from several different repositories

Public Repository

LocalRepository

What about corruption?

Major DVCS don’t trust anything

The DVCS is built to check for inadvertent or malicious corruption using security measures.

What if Squirrel wants Duck to become a co-developer?

internet/network

Public Repository

Local Repository

She can give him permission to the repository

Local Repository

LocalRepository

This model is similar to centralized version control in workflow, but they both still maintain there own fully functional repositories. And they can still push and pull from other sources.

What if there are many users and contributors?

internet/network

Looks chaotic, but it’s not as bad as it seems

Creative Commons attribution last slideFriday, February 26, 2010

internet/network

There are only 7 contributors to the project

internet/network

And Squirrel only pulls from two of them

For changes, there is a network of trust...

commits filter through the network sociallyFriday, February 26, 2010

Good, broadly applicable commits will work up the trust chain to Squirrel’s repository. If they are more domain or platform specific, they might stay within a sub-community of users.

Users and contributors trust Squirrel’s repository

And almost everybody pulls directly from it

What if the great commits don’t make it to Squirrel?

http://www.flickr.com/photos/cest_la_viva/3743305772/Friday, February 26, 2010

Open source code is a competition for ideas. Commits are small ideas that move through the network.

http://www.flickr.com/photos/cpurrin1/81055948/Friday, February 26, 2010

The strongest ideas will survive. And perhaps some only survive in niche environments.

internet/network

Graph is dynamic

And if Squirrel abandons the project, it is very easy to facilitate a change in leadership with DVCS.

Why does the open source community <3 DVCS?

Workflow

Open source projects have many different ways of organizing themselves. DVC allows for a lot of flexibility to accommodate these setups.

http://progit.org/book/ch5-1.html

Integration-Manager

Benevolent dictator

This is the Linux Kernel model. Linus Torvalds being the benevolent dictator.

Centralized

http://www.flickr.com/photos/bixentro/338430687/Friday, February 26, 2010

And any of these models can be patched together.

Politics

DVCS doesn’t remove politics from the open source community, but it does help a little.

Empowering (in a libertarian way)

Everybody gets full access to the code. You can do whatever you want.

Takes guesswork out of including people in

the project

Linus Torvalds gave this rationale in one of his talks. He said it is very hard to know who will have the great ideas to contribute. However, in centralized version control you have to make those determinations in advance, and give those people write access. With decentralized, you can let everybody make changes, and only incorporate the good ideas.

*Once you learn DVCSFriday, February 26, 2010

There is a learning curve, but things are easy once you have the knack.

http://www.flickr.com/photos/paperpariah/2607575751/sizes/o/Friday, February 26, 2010

Cloning and pushing commits is simple.

Branching (or branch like behavior) is very simple in DVCS. It’s painful in centralized systems.

http://www.flickr.com/photos/shanghaidaddy/1547549511/sizes/l/Friday, February 26, 2010

Everybody has a copy. And lots of copies keep things safe. The bigger the project, the safer the project.

http://www.flickr.com/photos/bpc009/3328427457/Friday, February 26, 2010

Major DVCS are built with security to protect the integrity of the code.

http://www.flickr.com/photos/zyx/3887062822/Friday, February 26, 2010

Easier to create and maintain. Less bribing of system admins.

These DVC systems can be fast. Like really fast. (A Git clone can be faster than a CVS checkout)

XCreative Commons http://www.flickr.com/photos/outerbankscandy/79480040/

There is no mothership. You don’t have to talk to a server with network lag. The internet could be down, and you would still be able to commit.

Fast + Easy = New Practices

Another interesting point made by Linus in one of his talks: When things are fast and easy, it changes how people work for the better.

Commit more often

Branch more often

Merge more often

Which is easier because the commits are smaller than a typical CVS commit.

How about CDL?

Why are we starting to pick up DVCS?

Fast & Easy

Fast and easy is a plus.

Creative Commons http://www.flickr.com/photos/janedoughnut/3857646512/sizes/l/Friday, February 26, 2010

Hopefully less tickets since DVCS needs less admin.

Definition of Colleague

I think this is our biggest reason.

Creative Commons http://www.flickr.com/photos/mirkogarufi/514406103/sizes/o/Friday, February 26, 2010

Our collaborators are now everywhere. Even on different continents.

Miscellany

Some related stuff I thought I’d throw in.

What’s this Git thingy and the Mecurial whatsy?

Open Source

Aegis ArXBazaarCodevilleDarcsDCVSFossil

GitGNU archLibreSourceMercurialMonotoneSVKTcldbrcs

Git and Mercurial and just one of many open source version control implementations. They are by far the most popular.

http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/Comparison is out of date, but the sentiment still holds.

There are often heated debates about them online. Beware of comparisons. Features and platform support for both are constantly changing, so mind the dates of the comparisons. This debate, though out of date, makes a good overall point. Git is a swiss army knife and impressive (MacGyver). Mercurial does version control simply and elegantly (Bond).

Creative Commons http://www.flickr.com/photos/unavoidablegrain/29657066/Friday, February 26, 2010

Choices? How do you choose between Git, Mercurial, or X?

Compatibility, Preference, Community

How is support on your platform/IDE? What do you like to use? What is your community using?

http://www.flickr.com/photos/guder/871202423/Friday, February 26, 2010

I think community is undervalued when institutions look at DVCS. If you are working on open source, there is a huge potential community. See what is common in your domain/language. Network effects can be a strong driver in the decision.

What’s Github?

internet/network

Public Repository Public

Repository

Local Repository

Github is a commercial company that provides hosting of public Git repositories. It is free for open source. They have a really nice UI, and make it very easy to collaborate.

Here is a screenshot.

Not to be outdone, Mercurial has a similar service called Bitbucket.

Where can I go for a more technical presentation?

http://gitcasts.com/posts/railsconf-git-talk

Scott Chacon’s Git Talk

This is a fantastic presentation! It’s Git specific, but Git shares a lot of concepts with other DVC implementations.

Questions?

http://www.flickr.com/photos/75905404@N00/445932304/

http://www.flickr.com/photos/ccdoh1/2702488155/

Creative Commons + Flickr (Thanks!)

http://www.flickr.com/photos/johnspooner/1675893179/

http://www.flickr.com/photos/pcoin/2827309845/

http://www.flickr.com/photos/e_phots/2410412512/

http://www.flickr.com/photos/dimitridf/424720855/

http://www.flickr.com/photos/martin_heigan/367388367/

http://www.flickr.com/photos/pietroizzo/544680448/

http://www.flickr.com/photos/leppyone/280204298/

http://www.flickr.com/photos/viamoi/3605272991/

http://www.flickr.com/photos/photosydney/58426279

http://www.flickr.com/photos/hvargas/2346549702/

http://www.flickr.com/photos/foxypar4/563798423/sizes/l/

http://www.flickr.com/photos/merlijnhoek/2841785343/

http://www.flickr.com/photos/vickispix/245953908/

http://www.flickr.com/photos/tsukikageyuu/1370326187/

http://www.flickr.com/photos/ucumari/2711488804/

Intro to Distributed Version Control

Technology