View
1.038
Download
3
Category
Tags:
Preview:
DESCRIPTION
I gave this talk at work about distributed version control. There is some background on version control, and centralized version control.
Citation preview
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
Friday, February 26, 2010
There are several names for the basic idea of software version control.
RCRevision Control
Friday, February 26, 2010
Some call it revision control.
SCMSource Code Management
Friday, February 26, 2010
Source Code Management is another one.
SCSource Control
Friday, February 26, 2010
One I use now and then is Source Control. Though sometimes there is nuanced, often these four are all used synonymously.
Centralized
CVC
CSCMCRC
CSC
Friday, February 26, 2010
Sometimes there are prefixed with Centralized, referring to the technical architecture of the implementation.
Distributed
DVC
DSCMDRC
DSC
Friday, February 26, 2010
Distributed refers to the architecture too. But it is all just a type of it is version control.
VCS
SCMS
RCSSystem
SCS
CVCS
CSCMS
CRCS
CSCS
DVCS
DSCMS
DRCS
DSCS
Friday, February 26, 2010
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
Friday, February 26, 2010
Though this is about software version control, the idea is not unique to software.
Documents/
Friday, February 26, 2010
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/
Friday, February 26, 2010
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
business_letter_old.doc
Documents/
Friday, February 26, 2010
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
business_letter_old.doc
Documents/
business_letter_02_24_2010.doc
Friday, February 26, 2010
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
business_letter_old.doc
Documents/
business_letter_02_24_2010.doc
business_letter_v1.doc
Friday, February 26, 2010
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
business_letter_old.doc
Documents/
business_letter_02_24_2010.doc
business_letter_v1.doc
business_letter_v1_cdf.doc
Friday, February 26, 2010
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.
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
Friday, February 26, 2010
for source code there is version control repositories
Friday, February 26, 2010
Friday, February 26, 2010
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
Friday, February 26, 2010
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.
Repository(Working) Directory
Friday, February 26, 2010
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.
Repository(Working) Directory
A
Initial CommitFriday, February 26, 2010
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.
RepositoryWorking Directory
A
Friday, February 26, 2010
RepositoryWorking Directory
A
Friday, February 26, 2010
RepositoryWorking Directory
A
B
Another CommitFriday, February 26, 2010
RepositoryWorking Directory
A
B
Friday, February 26, 2010
RepositoryWorking Directory
A
B
Friday, February 26, 2010
RepositoryWorking Directory
A
B
C
Third CommitFriday, February 26, 2010
Repository
Add | Modify | Delete
A
Friday, February 26, 2010
Software usually requires multiple dependent files, so version control can handle multiple files per commit.
Repository
Add | Modify | Delete
A
B
Friday, February 26, 2010
Software usually requires multiple dependent files, so version control can handle multiple files per commit.
Repository
Add | Modify | Delete
A
B
C
Friday, February 26, 2010
Software usually requires multiple dependent files, so version control can handle multiple files per commit.
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
A
B
C
Friday, February 26, 2010
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
A
B
C
Checkout B
Friday, February 26, 2010
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
A
B
C
Checkout C
Checkout B
Friday, February 26, 2010
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.
Why Version Control?
Friday, February 26, 2010
There are many reasons why version control is helpful for development.
Rollback
Friday, February 26, 2010
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
Friday, February 26, 2010
VC helps support the development workflow as well.
Respository
Friday, February 26, 2010
Let’s start with a simple repository.
Trunk
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.
Trunk
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.
Trunk
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.
Trunk
Branch
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.
Trunk
Branch
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.
Trunk
Branch
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.
Trunk
Branch
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.
Trunk
Branch
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.
Trunk
Branch
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.
Trunk
Branch
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.
Trunk
Branch
Merge
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.
How does that work?
Friday, February 26, 2010
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!
Friday, February 26, 2010
If not, it will give you a conflict warning.
You figure it out.
Friday, February 26, 2010
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)
Friday, February 26, 2010
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
Friday, February 26, 2010
VC systems often have a simple feature to help with releases.
A
B
C
D
E
F
G
H
Commits Tags
Release 1.0
Release 1.1
Friday, February 26, 2010
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
Friday, February 26, 2010
The history is one of the most important features, especially for collaboration.
Author
Time/Date
Comment
Friday, February 26, 2010
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
Friday, February 26, 2010
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
Friday, February 26, 2010
Centralized Version control has been around for almost 30 years. CVS and SVN are popular implementations.
One Repository...
Central
Repository
Friday, February 26, 2010
...used by one or more developers
as represented by my favorite Lake Merritt residents
attribution last slideFriday, February 26, 2010
internet/network
Central
Repository
Friday, February 26, 2010
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
A
B
C
Checkout C
Friday, February 26, 2010
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
Friday, February 26, 2010
So here’s an example with a empty repository.
internet/network
Central
Repository
A
Duck commits A
A
Friday, February 26, 2010
Duck creates some code and commits it. It because commit A.
internet/network
Central
Repository
A
Everybody else checks out version A
A A A
Friday, February 26, 2010
Squirrel and Pidgin download the code from the repository.
internet/network
Central
Repository
A B
B
Pidgin commits B
AA
Friday, February 26, 2010
Pidgin makes some changes and commits B to the repository.
internet/network
Central
Repository
A B
A C B
Squirrel tries to commit version C
Friday, February 26, 2010
Squirrel makes some changes too and tries to commit them.
Conflict!
Friday, February 26, 2010
Doh! Squirrel didn’t have Pidgin’s changes in commit B, so now there is a conflict.
internet/network
Central
Repository
CA B
A C B
Squirrel merges and commits version C
Friday, February 26, 2010
After a merge, then Squirrel can commit the changes to the central repository.
internet/network
Central
Repository
CA B
C C C
Duck and Pidgin update to version C
Friday, February 26, 2010
Everybody updates there code from the repository, and they are all on the same page again.
How do you avoid a conflict?
Friday, February 26, 2010
Update frequently
Friday, February 26, 2010
Try to find the conflicts before they get big. If there is one, you’ll get it when you update.
Coordinate
Friday, February 26, 2010
Try not to be working on the same thing at the same time.
internet/network
Central
Repository
Admin
Pidgin admins the repository on the server
Friday, February 26, 2010
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
Friday, February 26, 2010
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?”
No
Friday, February 26, 2010
The short answer.
How?
Friday, February 26, 2010
The short reply.
Local
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
Local
Repository
Squirrel begins committing to the local repository
A
B
Friday, February 26, 2010
Once she creates the repository she can commit her code changes to it. It is a fully functional repository.
internet/network
Local Repository
A B
Squirrel creates a public repository
Public Repository
Friday, February 26, 2010
Squirrel decides it might be useful to other people, and creates a publicly accessible repository.
internet/network
Public Repository
Local Repository
A B
She pushes changes to the repository
A B
Friday, February 26, 2010
internet/network
Public Repository
Local Repository
A B
Duck decides to use Squirrel’s project
A B
(The other way to start out)Friday, February 26, 2010
internet/network
Public Repository
Local Repository
A B
He clones Squirrel’s public repository
A B
Local Repository
A B
Friday, February 26, 2010
Duck now has the complete version history.
internet/network
Public Repository
Local Repository
Squirrel adds commit “C” to the local repository
A B
Local Repository
A B
CA B
Friday, February 26, 2010
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
A B
CA B
CA B
Friday, February 26, 2010
internet/network
Public Repository
Local Repository
Duck pulls changes from Squirrel’s public repository
Local Repository
CA B
CA B
CA B
Friday, February 26, 2010
internet/network
Public Repository
Local Repository
He makes his own commits to his local repository
Local Repository
CA B
CA B
CA B
FD E
Friday, February 26, 2010
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
CA B
CA B
CA B
X
FD E
Friday, February 26, 2010
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
CA B
CA B
CA B
PublicRepository
FD E
Friday, February 26, 2010
internet/network
Public Repository
Local Repository
Duck pushes to his public repository
Local Repository
CA B
CA B
CA B
PublicRepository
CA B
FD E
FD E
Friday, February 26, 2010
internet/network
Public Repository
Local Repository
Duck notifies Squirrel of his spiffy changes through email, or whatever
Local Repository
CA B
CA B
CA B
PublicRepository
CA B
FD E
FD E
Friday, February 26, 2010
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
CA B
CA B
CA B
Public Repository
CA B
FD E
FD E
FD E
Friday, February 26, 2010
internet/network
Public Repository
Local Repository
She then pushes them to her public repository
Local Repository
CA B
CA B
CA B
PublicRepository
CA B
FD E
FD E
FD E
FD E
Friday, February 26, 2010
internet/network
Public Repository
Local Repository
And there you have it!
Local Repository
CA B
CA B
CA B
Public Repository
CA B
FD E
FD E
FD E
FD E
Friday, February 26, 2010
Everybody has the same revisions in their repositories.
A few things to note
Friday, February 26, 2010
What if Squirrel had coded some more changes?
Friday, February 26, 2010
internet/network
Public Repository
Local Repository
Local Repository
CA B
CA B
CA B
Public Repository
CA B
G
FD E
FD E
XConflict!
Friday, February 26, 2010
internet/network
Public Repository
Local Repository
Local Repository
CA B
CA B
CA B
Public Repository
CA B
G
FD E
FD E
FD E
Squirrel merges the changes to her local repository
Friday, February 26, 2010
What if Squirrel doesn’t like Duck’s changes?
Friday, February 26, 2010
internet/network
Public Repository
Local Repository
She doesn’t need to pull them, ever
Local Repository
CA B
CA B
CA B
PublicRepository
CA B
X
FD E
FD E
Friday, February 26, 2010
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?
Friday, February 26, 2010
internet/network
Public Repository
Local Repository
Nothing stops other users from cloning/pulling
Local Repository
CA B
CA B
CA B
Public Repository
CA B
LocalRepository
CA B
FD E
FD E
FD E
Friday, February 26, 2010
internet/network
Public Repository
You can pull from several different repositories
Public Repository
LocalRepository
Friday, February 26, 2010
What about corruption?
Friday, February 26, 2010
Major DVCS don’t trust anything
Friday, February 26, 2010
The DVCS is built to check for inadvertent or malicious corruption using security measures.
What if Squirrel wants Duck to become a co-developer?
Friday, February 26, 2010
internet/network
Public Repository
Local Repository
She can give him permission to the repository
Local Repository
LocalRepository
Friday, February 26, 2010
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?
Friday, February 26, 2010
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
Friday, February 26, 2010
internet/network
And Squirrel only pulls from two of them
Friday, February 26, 2010
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
Friday, February 26, 2010
What if the great commits don’t make it to Squirrel?
Friday, February 26, 2010
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
Friday, February 26, 2010
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?
Friday, February 26, 2010
Workflow
Friday, February 26, 2010
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
Solo
Friday, February 26, 2010
http://progit.org/book/ch5-1.html
Integration-Manager
Friday, February 26, 2010
http://progit.org/book/ch5-1.html
Benevolent dictator
Friday, February 26, 2010
This is the Linux Kernel model. Linus Torvalds being the benevolent dictator.
http://progit.org/book/ch5-1.html
Centralized
Friday, February 26, 2010
http://www.flickr.com/photos/bixentro/338430687/Friday, February 26, 2010
And any of these models can be patched together.
Politics
Friday, February 26, 2010
DVCS doesn’t remove politics from the open source community, but it does help a little.
Empowering (in a libertarian way)
Friday, February 26, 2010
Everybody gets full access to the code. You can do whatever you want.
Takes guesswork out of including people in
the project
Friday, February 26, 2010
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.
Easy*
*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.
Friday, February 26, 2010
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.
Fast
Friday, February 26, 2010
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/
Friday, February 26, 2010
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
Friday, February 26, 2010
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
Friday, February 26, 2010
Branch more often
Friday, February 26, 2010
Merge more often
Friday, February 26, 2010
Which is easier because the commits are smaller than a typical CVS commit.
How about CDL?
Friday, February 26, 2010
Why are we starting to pick up DVCS?
Fast & Easy
Friday, February 26, 2010
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
Friday, February 26, 2010
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
Friday, February 26, 2010
Some related stuff I thought I’d throw in.
What’s this Git thingy and the Mecurial whatsy?
Friday, February 26, 2010
Open Source
Aegis ArXBazaarCodevilleDarcsDCVSFossil
GitGNU archLibreSourceMercurialMonotoneSVKTcldbrcs
Friday, February 26, 2010
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.
Friday, February 26, 2010
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
Friday, February 26, 2010
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?
Friday, February 26, 2010
internet/network
Public Repository Public
Repository
Local Repository
Local Repository
Friday, February 26, 2010
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.
Friday, February 26, 2010
Here is a screenshot.
Friday, February 26, 2010
Not to be outdone, Mercurial has a similar service called Bitbucket.
Where can I go for a more technical presentation?
Friday, February 26, 2010
http://gitcasts.com/posts/railsconf-git-talk
Scott Chacon’s Git Talk
Friday, February 26, 2010
This is a fantastic presentation! It’s Git specific, but Git shares a lot of concepts with other DVC implementations.
Questions?
Friday, February 26, 2010
http://www.flickr.com/photos/75905404@N00/445932304/
http://www.flickr.com/photos/ccdoh1/2702488155/
Creative Commons + Flickr (Thanks!)
http://www.flickr.com/photos/7202153@N03/2780298470/
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/66164549@N00/2461340910/
http://www.flickr.com/photos/tsukikageyuu/1370326187/
http://www.flickr.com/photos/ucumari/2711488804/
Friday, February 26, 2010
Recommended