Intro to Distributed Version Control

1,163
-1

Published on

I gave this talk at work about distributed version control. There is some background on version control, and centralized version control.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,163
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
48
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Intro to Distributed Version Control

  1. 1. DVC Distributed 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.
  2. 2. VC Version Control Friday, February 26, 2010 There are several names for the basic idea of software version control.
  3. 3. RC Revision Control Friday, February 26, 2010 Some call it revision control.
  4. 4. SCM Source Code Management Friday, February 26, 2010 Source Code Management is another one.
  5. 5. SC Source 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.
  6. 6. CVC CRC Centralized CSCM CSC Friday, February 26, 2010 Sometimes there are prefixed with Centralized, referring to the technical architecture of the implementation.
  7. 7. DVC DRC Distributed DSCM DSC Friday, February 26, 2010 Distributed refers to the architecture too. But it is all just a type of it is version control.
  8. 8. VCS CVCS DVCS RCS CRCS DRCS System SCMS CSCMS DSCMS SCS CSCS DSCS Friday, February 26, 2010 Systems is often suffixed to refer to the technical implementations of version control.
  9. 9. 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.
  10. 10. Version Control Friday, February 26, 2010 Though this is about software version control, the idea is not unique to software.
  11. 11. 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.
  12. 12. Documents/ business_letter.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.
  13. 13. Documents/ business_letter.doc business_letter_old.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.
  14. 14. Documents/ business_letter.doc business_letter_old.doc 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.
  15. 15. Documents/ business_letter.doc business_letter_old.doc 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.
  16. 16. Documents/ business_letter.doc business_letter_old.doc 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.
  17. 17. http://www.flickr.com/photos/wokka/2836512221/ Friday, February 26, 2010 This can get cluttered very fast.
  18. 18. 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.
  19. 19. for documents there is track changes Friday, February 26, 2010
  20. 20. for source code there is version control repositories Friday, February 26, 2010
  21. 21. 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.
  22. 22. (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.
  23. 23. (Working) Directory Repository 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.
  24. 24. (Working) Directory Repository A Initial Commit 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.
  25. 25. Working Directory Repository A Friday, February 26, 2010
  26. 26. Working Directory Repository A Friday, February 26, 2010
  27. 27. Working Directory Repository A B Another Commit Friday, February 26, 2010
  28. 28. Working Directory Repository A B Friday, February 26, 2010
  29. 29. Working Directory Repository A B Friday, February 26, 2010
  30. 30. Working Directory Repository A B C Third Commit Friday, February 26, 2010
  31. 31. Repository A Add | Modify | Delete Friday, February 26, 2010 Software usually requires multiple dependent files, so version control can handle multiple files per commit.
  32. 32. Repository A B Add | Modify | Delete Friday, February 26, 2010 Software usually requires multiple dependent files, so version control can handle multiple files per commit.
  33. 33. Repository A B C Add | Modify | Delete Friday, February 26, 2010 Software usually requires multiple dependent files, so version control can handle multiple files per commit.
  34. 34. 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.
  35. 35. 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.
  36. 36. Repository Checkout B 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.
  37. 37. Repository Checkout B A B C Checkout 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.
  38. 38. Why Version Control? Friday, February 26, 2010 There are many reasons why version control is helpful for development.
  39. 39. Rollback Friday, February 26, 2010 Being able to rollback to a previous version is the most useful thing about VC.
  40. 40. 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.)
  41. 41. Development Friday, February 26, 2010 VC helps support the development workflow as well.
  42. 42. Respository Friday, February 26, 2010 Let’s start with a simple repository.
  43. 43. 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.
  44. 44. 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.
  45. 45. 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.
  46. 46. 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.
  47. 47. 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.
  48. 48. 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.
  49. 49. 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.
  50. 50. 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.
  51. 51. 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.
  52. 52. 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.
  53. 53. 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.
  54. 54. How does that work? Friday, February 26, 2010
  55. 55. 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.
  56. 56. Conflict! Friday, February 26, 2010 If not, it will give you a conflict warning.
  57. 57. You figure it out. Friday, February 26, 2010
  58. 58. 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.
  59. 59. Release Friday, February 26, 2010 VC systems often have a simple feature to help with releases.
  60. 60. Commits Tags A B C D Release 1.0 E F G Release 1.1 H 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.
  61. 61. History Friday, February 26, 2010 The history is one of the most important features, especially for collaboration.
  62. 62. 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.
  63. 63. Collaborate Friday, February 26, 2010 Major VC systems allow for collaboration by allowing people to share repositories or commits.
  64. 64. http://www.flickr.com/photos/healfdene/2580099594/ Friday, February 26, 2010
  65. 65. Centralized Version Control Friday, February 26, 2010 Centralized Version control has been around for almost 30 years. CVS and SVN are popular implementations.
  66. 66. One Repository... Central Repository Friday, February 26, 2010
  67. 67. ...used by one or more developers as represented by my favorite Lake Merritt residents attribution last slide Friday, February 26, 2010
  68. 68. internet/network Central Repository Friday, February 26, 2010 Each one of these developers has access to the repository.
  69. 69. 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.
  70. 70. 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.
  71. 71. Central repository is empty internet/network Central Repository Friday, February 26, 2010 So here’s an example with a empty repository.
  72. 72. Duck commits A internet/network A Central Repository A Friday, February 26, 2010 Duck creates some code and commits it. It because commit A.
  73. 73. Everybody else checks out version A internet/network A Central Repository A A A Friday, February 26, 2010 Squirrel and Pidgin download the code from the repository.
  74. 74. Pidgin commits B internet/network A B Central Repository A A B Friday, February 26, 2010 Pidgin makes some changes and commits B to the repository.
  75. 75. Squirrel tries to commit version C internet/network A B Central Repository A C B Friday, February 26, 2010 Squirrel makes some changes too and tries to commit them.
  76. 76. Conflict! Friday, February 26, 2010 Doh! Squirrel didn’t have Pidgin’s changes in commit B, so now there is a conflict.
  77. 77. Squirrel merges and commits version C internet/network A B C Central Repository A C B Friday, February 26, 2010 After a merge, then Squirrel can commit the changes to the central repository.
  78. 78. Duck and Pidgin update to version C internet/network A B C Central Repository C C C Friday, February 26, 2010 Everybody updates there code from the repository, and they are all on the same page again.
  79. 79. How do you avoid a conflict? Friday, February 26, 2010
  80. 80. 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.
  81. 81. Coordinate Friday, February 26, 2010 Try not to be working on the same thing at the same time.
  82. 82. Pidgin admins the repository on the server internet/network Central Repository Admin 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.
  83. 83. Distributed Version Control Friday, February 26, 2010 With distributed version control EVERYBODY gets there own repository. In fact, many people get more than one.
  84. 84. 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?”
  85. 85. No Friday, February 26, 2010 The short answer.
  86. 86. How? Friday, February 26, 2010 The short reply.
  87. 87. Squirrel creates a repository on her local machine Local Repository (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.
  88. 88. Squirrel begins committing to the local repository Commits A Local Repository B Friday, February 26, 2010 Once she creates the repository she can commit her code changes to it. It is a fully functional repository.
  89. 89. Squirrel creates a public repository Local Repository A B internet/network Public Repository Friday, February 26, 2010 Squirrel decides it might be useful to other people, and creates a publicly accessible repository.
  90. 90. She pushes changes to the repository Local Repository A B internet/network Public Repository A B Friday, February 26, 2010
  91. 91. Duck decides to use Squirrel’s project Local Repository A B internet/network Public Repository A B (The other way to start out) Friday, February 26, 2010
  92. 92. He clones Squirrel’s public repository Local Repository A B internet/network Public Repository A B Local Repository A B Friday, February 26, 2010 Duck now has the complete version history.
  93. 93. Squirrel adds commit “C” to the local repository Local Repository A B C internet/network Public Repository A B Local Repository A B Friday, February 26, 2010 Squirrel makes a change and commits it to the local repository.
  94. 94. She pushes changes to the public repository Local Repository A B C internet/network Public Repository A B C Local Repository A B Friday, February 26, 2010
  95. 95. Duck pulls changes from Squirrel’s public repository Local Repository A B C internet/network Public Repository A B C Local Repository A B C Friday, February 26, 2010
  96. 96. He makes his own commits to his local repository Local Repository A B C internet/network Public Repository A B C Local Repository A B C D E F Friday, February 26, 2010 Duck makes some changes to the code for his own use.
  97. 97. But he can’t push his changes to Squirrel’s public repository Local Repository A B C internet/network Public Repository A B C Local X Repository A B C D E F 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.
  98. 98. Duck creates a public repository Local Repository A B C internet/network Public Public Repository Repository A B C Local Repository A B C D E F Friday, February 26, 2010
  99. 99. Duck pushes to his public repository Local Repository A B C internet/network Public Public Repository Repository A B C A B C D E F Local Repository A B C D E F Friday, February 26, 2010
  100. 100. Duck notifies Squirrel of his spiffy changes through email, or whatever Local Repository A B C internet/network Public Public Repository Repository A B C A B C D E F Local Repository A B C D E F Friday, February 26, 2010 Hopefully Squirrel has listed her email or how she wants to be contacted for patches.
  101. 101. She likes the changes and pulls them Local Repository A B C D E F internet/network Public Public Repository Repository A B C A B C D E F Local Repository A B C D E F Friday, February 26, 2010
  102. 102. She then pushes them to her public repository Local Repository A B C D E F internet/network Public Public Repository Repository A B C A B C D E F D E F Local Repository A B C D E F Friday, February 26, 2010
  103. 103. And there you have it! Local Repository A B C D E F internet/network Public Public Repository Repository A B C A B C D E F D E F Local Repository A B C D E F Friday, February 26, 2010 Everybody has the same revisions in their repositories.
  104. 104. A few things to note Friday, February 26, 2010
  105. 105. What if Squirrel had coded some more changes? Friday, February 26, 2010
  106. 106. Local Repository Conflict! A B C X G internet/network Public Public Repository Repository A B C A B C D E F Local Repository A B C D E F Friday, February 26, 2010
  107. 107. Squirrel merges the changes to her local repository Local Repository A B C D E F G internet/network Public Public Repository Repository A B C A B C D E F Local Repository A B C D E F Friday, February 26, 2010
  108. 108. What if Squirrel doesn’t like Duck’s changes? Friday, February 26, 2010
  109. 109. She doesn’t need to pull them, ever Local Repository X A B C internet/network Public Public Repository Repository A B C A B C D E F Local Repository A B C D E F Friday, February 26, 2010 If they are friends or colleagues, VC does not socially moderate the implications of rejection. You are on your own.
  110. 110. But what if they are super cool, and they would be useful to other users? Friday, February 26, 2010
  111. 111. Nothing stops other users from cloning/pulling Local Local Repository Repository A B C A B C D E F internet/network Public Public Repository Repository A B C A B C D E F Local Repository A B C D E F Friday, February 26, 2010
  112. 112. You can pull from several different repositories Local Repository internet/network Public Public Repository Repository Friday, February 26, 2010
  113. 113. What about corruption? Friday, February 26, 2010
  114. 114. Major DVCS don’t trust anything Friday, February 26, 2010 The DVCS is built to check for inadvertent or malicious corruption using security measures.
  115. 115. What if Squirrel wants Duck to become a co-developer? Friday, February 26, 2010
  116. 116. She can give him permission to the repository Local Repository internet/network Public Repository Local Local Repository Repository 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.
  117. 117. What if there are many users and contributors? Friday, February 26, 2010
  118. 118. Looks chaotic, but it’s not as bad as it seems internet/network Creative Commons attribution last slide Friday, February 26, 2010
  119. 119. There are only 7 contributors to the project internet/network Friday, February 26, 2010
  120. 120. And Squirrel only pulls from two of them internet/network Friday, February 26, 2010
  121. 121. For changes, there is a network of trust... commits filter through the network socially Friday, 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.
  122. 122. Users and contributors trust Squirrel’s repository And almost everybody pulls directly from it Friday, February 26, 2010
  123. 123. What if the great commits don’t make it to Squirrel? Friday, February 26, 2010
  124. 124. 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.
  125. 125. http://www.flickr.com/photos/cpurrin1/81055948/ Friday, February 26, 2010 The strongest ideas will survive. And perhaps some only survive in niche environments.
  126. 126. Graph is dynamic internet/network Friday, February 26, 2010 And if Squirrel abandons the project, it is very easy to facilitate a change in leadership with DVCS.
  127. 127. Why does the open source community <3 DVCS? Friday, February 26, 2010
  128. 128. 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.
  129. 129. Solo http://progit.org/book/ch5-1.html Friday, February 26, 2010
  130. 130. Integration-Manager http://progit.org/book/ch5-1.html Friday, February 26, 2010
  131. 131. Benevolent dictator http://progit.org/book/ch5-1.html Friday, February 26, 2010 This is the Linux Kernel model. Linus Torvalds being the benevolent dictator.
  132. 132. Centralized http://progit.org/book/ch5-1.html Friday, February 26, 2010
  133. 133. http://www.flickr.com/photos/bixentro/338430687/ Friday, February 26, 2010 And any of these models can be patched together.
  134. 134. Politics Friday, February 26, 2010 DVCS doesn’t remove politics from the open source community, but it does help a little.
  135. 135. Empowering (in a libertarian way) Friday, February 26, 2010 Everybody gets full access to the code. You can do whatever you want.
  136. 136. 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.
  137. 137. Easy* *Once you learn DVCS Friday, February 26, 2010 There is a learning curve, but things are easy once you have the knack.
  138. 138. http://www.flickr.com/photos/paperpariah/2607575751/sizes/o/ Friday, February 26, 2010 Cloning and pushing commits is simple.
  139. 139. Friday, February 26, 2010 Branching (or branch like behavior) is very simple in DVCS. It’s painful in centralized systems.
  140. 140. 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.
  141. 141. http://www.flickr.com/photos/bpc009/3328427457/ Friday, February 26, 2010 Major DVCS are built with security to protect the integrity of the code.
  142. 142. http://www.flickr.com/photos/zyx/3887062822/ Friday, February 26, 2010 Easier to create and maintain. Less bribing of system admins.
  143. 143. Fast Friday, February 26, 2010 These DVC systems can be fast. Like really fast. (A Git clone can be faster than a CVS checkout)
  144. 144. Friday, February 26, 2010 X Creative 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.
  145. 145. 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.
  146. 146. Commit more often Friday, February 26, 2010
  147. 147. Branch more often Friday, February 26, 2010
  148. 148. Merge more often Friday, February 26, 2010 Which is easier because the commits are smaller than a typical CVS commit.
  149. 149. How about CDL? Friday, February 26, 2010 Why are we starting to pick up DVCS?
  150. 150. Fast & Easy Friday, February 26, 2010 Fast and easy is a plus.
  151. 151. Creative Commons http://www.flickr.com/photos/janedoughnut/3857646512/sizes/l/ Friday, February 26, 2010 Hopefully less tickets since DVCS needs less admin.
  152. 152. Definition of Colleague Friday, February 26, 2010 I think this is our biggest reason.
  153. 153. Creative Commons http://www.flickr.com/photos/mirkogarufi/514406103/sizes/o/ Friday, February 26, 2010 Our collaborators are now everywhere. Even on different continents.
  154. 154. Miscellany Friday, February 26, 2010 Some related stuff I thought I’d throw in.
  155. 155. What’s this Git thingy and the Mecurial whatsy? Friday, February 26, 2010
  156. 156. Open Source Aegis Git ArX GNU arch Bazaar LibreSource Codeville Mercurial Darcs Monotone DCVS SVK Fossil Tcldbrcs Friday, February 26, 2010 Git and Mercurial and just one of many open source version control implementations. They are by far the most popular.
  157. 157. Comparison is out of date, but the sentiment still holds. http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ 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).
  158. 158. Creative Commons http://www.flickr.com/photos/unavoidablegrain/29657066/ Friday, February 26, 2010 Choices? How do you choose between Git, Mercurial, or X?
  159. 159. 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?
  160. 160. 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.
  161. 161. What’s Github? Friday, February 26, 2010
  162. 162. Local Repository internet/network Public Public Repository 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.
  163. 163. Friday, February 26, 2010 Here is a screenshot.
  164. 164. Friday, February 26, 2010 Not to be outdone, Mercurial has a similar service called Bitbucket.
  165. 165. Where can I go for a more technical presentation? Friday, February 26, 2010
  166. 166. Scott Chacon’s Git Talk http://gitcasts.com/posts/railsconf-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.
  167. 167. Questions? Friday, February 26, 2010
  168. 168. http://www.flickr.com/photos/66164549@N00/2461340910/ Creative Commons + Flickr (Thanks!) http://www.flickr.com/photos/ucumari/2711488804/ http://www.flickr.com/photos/viamoi/3605272991/ http://www.flickr.com/photos/foxypar4/563798423/sizes/l/ http://www.flickr.com/photos/7202153@N03/2780298470/ http://www.flickr.com/photos/75905404@N00/445932304/ http://www.flickr.com/photos/johnspooner/1675893179/ http://www.flickr.com/photos/ccdoh1/2702488155/ http://www.flickr.com/photos/pcoin/2827309845/ http://www.flickr.com/photos/tsukikageyuu/1370326187/ http://www.flickr.com/photos/e_phots/2410412512/ http://www.flickr.com/photos/photosydney/58426279 http://www.flickr.com/photos/dimitridf/424720855/ http://www.flickr.com/photos/hvargas/2346549702/ http://www.flickr.com/photos/martin_heigan/367388367/ http://www.flickr.com/photos/merlijnhoek/2841785343/ http://www.flickr.com/photos/pietroizzo/544680448/ http://www.flickr.com/photos/vickispix/245953908/ http://www.flickr.com/photos/leppyone/280204298/ Friday, February 26, 2010

×