Your SlideShare is downloading. ×
0
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Source Control Extravaganza!
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Source Control Extravaganza!

491

Published on

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

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

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

  • Be the first to like this

No Downloads
Views
Total Views
491
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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...
    TTB
  • 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.
    disadvantages:
    * 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.
  • Transcript

    • 1. Source Control
    • 2. a history
    • 3. a “history”
    • 4. The Programmer’s Dilemma a natural history of four source control systems
    • 5. 1.
    • 6. SCCS
    • 7. RCS
    • 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. RCS
    • 10. CVS
    • 11. edit merge commit
    • 12. branch/merge
    • 13. tag
    • 14. CVS
    • 15. subversion
    • 16. atomic!
    • 17. atomic! http://www.flickr.com/photos/sakucae/3686680582/
    • 18. branch = copy
    • 19. 2.
    • 20. ClearCase
    • 21. base
    • 22. UCM
    • 23. checkout
    • 24. snapshot views
    • 25. dynamic views
    • 26. merge arrows
    • 27. 3.
    • 28. TFS
    • 29. 4.
    • 30. git
    • 31. commit e83c5163316f89bfbde7d9ab23ca2e25604af290 Author: Linus Torvalds <torvalds@ppc970.osdl.org> Date: Thu Apr 7 15:13:13 2005 -0700 Initial revision of "git", the information manager from hell
    • 32. distributed
    • 33. • arch • darcs • mercurial • bazaar
    • 34. practices
    • 35. mainline
    • 36. branch per feature
    • 37. promotion
    • 38. double merge
    • 39. git example
    • 40. git add sample.txt
    • 41. git commit
    • 42. (edit sample.txt) git add -u git commit
    • 43. git mv sample.txt renamed.txt git commit
    • 44. git checkout -b other git add a git commit
    • 45. git merge master
    • 46. git checkout master git merge
    • 47. • Software Configuration Management Patterns, by Steve Berczuk with Brad Appleton (http://scmpatterns.com/) • git • Pro Git, by Scott Chacon (http:// progit.org) • Git Parable (http://lmgtfy.com/?q=git +parable) • http://git-scm.com/
    • 48. Thank you! Matt Burke <maburke@sep.com> http://mattonrails.wordpress.com/ http://www.slideshare.net/spraints/overview-of-source-control-systemskey

    ×