Source Control Extravaganza!


Published on

A talk given by Matt for IndyALT.NET in October 2009.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Who uses source control at work?
    Who uses it for sample projects?
  • Far from complete or accurate. But it will highlight some features, and how they progressed.

    This will be unix-centric, but I’ll pull in Windows stuff that I know about.
  • in ancient times, there was SCCS.
  • “revision control system”
    1982 (man1) - 1995 (wikipedia)
  • revisions are tracked in a “,v” file in the same directory.
  • 1986 (man1)
    built on RCS:
    * client-server!
  • 2000 (wikipedia)
    replacement for CVS, especially for its design flaws.
    still client/server
  • subversion operations are atomic.
    individual file revisions are grouped into revisions, one message, many files updated.
  • subversion operations are atomic.
    individual file revisions are grouped into revisions, one message, many files updated.
  • because branches are just another directory in the source tree...
    because directories are versioned along with files...
  • 1992 (wikipedia)
  • client/server
    version control of “elements” -- directories or files.
    very unixy.
  • an entire software development methodology.
  • a difference between CVS and CC, and more generally a difference between free/open-source source control and proprietary source control.
  • In clearcase, the sandbox is called a view.
    one mode for views is “snapshot” -- just like any other source control system, you explicitly say when to update your local copy.
  • ClearCase has a novel alternative: a virtual drive that contains your view. Updates to files are immediately available. A “config spec” tells the server the rules to follow when showing you files.
  • when you branch in clearcase, like in RCS or CVS, it’s stored as a fork in the version tree for an element.

    When you merge branches, CC keeps track of which versions were the parent version of an version via “arrows”. Even when you merge conflicting changes on the same branch, clearcase makes arrows for those, too.

    Tracking this information makes it easier to do future merges, because you know that the stuff before the arrow is already taken care of.
  • team foundation server, ~2006.
    source control is similar to subversion -- branch is directory, changesets are atomic.
  • “more than meets the eye”
    full lifecycle management: work items, document (sharepoint), ssas/ssrs
  • 2005 (git source history)
  • each sandbox is a complete copy of the source tree and history.
    commits are 100% local.
    merging is well thought-out (because it’s essential), and easy to back out of at any point.
    i’ll show an example later.
  • some other systems
  • simple!
  • advantage: more control over what code is released.
    * requires a merge master
    * merging is often complicated and can lose code
    * it’s hard to share code between uncompleted features
    * CI is harder
    (unless you’re using a distributed source control tool)
  • either move a label along or merge to a branch.
    moving a label along is very simple, we use it now. merging is a pain (unless you’re using git)
  • if you’re dealing with branches, and the branch has conflicts (or it’s been around long enough that it even might have conflicts) with the mainline MERGE FROM MASTER TO YOUR BRANCH, then merge the result back.
    (in git, this doesn’t matter quite as much, but the merge back is TRIVIAL).
  • why is merging easier with git? an example might help
  • when you “add” a file to git’s index, it makes a blob, with a sha1 hash of the file’s contents.
  • when you check in your index’s contents, git makes a commit, which has a tree, which has your blob. the tree is the directory.
  • add -u updates any files git is tracking.
  • now there are two commits, each with a tree and a different version of sample.txt.
  • how do renames work? (any ideas from audience)
  • content is the same, so git doesn’t store another copy of the file, but makes a new tree and a new commit.
  • Let’s make a branch, and add a file to it. In the meantime, someone added a file to master (the default branch), too.
  • From the “other” branch, we merge master in...
  • so now other has a commit with two parents.
  • what happens when we merge from other to master? (ideas from audience)
  • git does a “fast forward” merge, which basically means it just moves where the name “master” points.
  • Source Control Extravaganza!

    1. 1. Source Control
    2. 2. a history
    3. 3. a “history”
    4. 4. The Programmer’s Dilemma a natural history of four source control systems
    5. 5. 1.
    6. 6. SCCS
    7. 7. RCS
    8. 8. $ ci sample.txt sample.txt,v <-- sample.txt enter description, terminated with single '.' or end of file: NOTE: This is NOT the log message! >> Created a sample checkin. >> . initial revision: 1.1 done $ ls sample.txt,v $ co sample.txt sample.txt,v --> sample.txt revision 1.1 done $ ls sample.txt sample.txt,v
    9. 9. RCS
    10. 10. CVS
    11. 11. edit merge commit
    12. 12. branch/merge
    13. 13. tag
    14. 14. CVS
    15. 15. subversion
    16. 16. atomic!
    17. 17. atomic!
    18. 18. branch = copy
    19. 19. 2.
    20. 20. ClearCase
    21. 21. base
    22. 22. UCM
    23. 23. checkout
    24. 24. snapshot views
    25. 25. dynamic views
    26. 26. merge arrows
    27. 27. 3.
    28. 28. TFS
    29. 29. 4.
    30. 30. git
    31. 31. commit e83c5163316f89bfbde7d9ab23ca2e25604af290 Author: Linus Torvalds <> Date: Thu Apr 7 15:13:13 2005 -0700 Initial revision of "git", the information manager from hell
    32. 32. distributed
    33. 33. • arch • darcs • mercurial • bazaar
    34. 34. practices
    35. 35. mainline
    36. 36. branch per feature
    37. 37. promotion
    38. 38. double merge
    39. 39. git example
    40. 40. git add sample.txt
    41. 41. git commit
    42. 42. (edit sample.txt) git add -u git commit
    43. 43. git mv sample.txt renamed.txt git commit
    44. 44. git checkout -b other git add a git commit
    45. 45. git merge master
    46. 46. git checkout master git merge
    47. 47. • Software Configuration Management Patterns, by Steve Berczuk with Brad Appleton ( • git • Pro Git, by Scott Chacon (http:// • Git Parable ( +parable) •
    48. 48. Thank you! Matt Burke <>