Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Similar to Source Control Extravaganza!
Similar to Source Control Extravaganza! (20)
Recently uploaded
Recently uploaded (20)
Source Control Extravaganza!
- 2. a history
- 3. a “history”
- 4. The Programmer’s Dilemma a natural history of four source control systems
- 5. 1.
- 7. SCCS
- 8. RCS
- 9. $ 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
- 10. RCS
- 11. CVS
- 13. branch/merge
- 14. tag
- 15. CVS
- 16. subversion
- 17. atomic!
- 18. atomic! http://www.flickr.com/photos/sakucae/3686680582/
- 19. branch = copy
- 20. 2.
- 21. ClearCase
- 22. base
- 23. UCM
- 24. checkout
- 25. snapshot views
- 26. dynamic views
- 27. merge arrows
- 28. 3.
- 29. TFS
- 31. 4.
- 32. git
- 33. 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
- 34. distributed
- 35. • arch • darcs • mercurial • bazaar
- 36. practices
- 37. mainline
- 39. promotion
- 40. double merge
- 41. git example
- 43. git commit
- 44. (edit sample.txt) git add -u git commit
- 46. git mv sample.txt renamed.txt git commit
- 48. git checkout -b other git add a git commit
- 50. git merge master
- 52. git checkout master git merge
- 54. • 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/
- 55. Thank you! Matt Burke <maburke@sep.com> http://mattonrails.wordpress.com/ http://www.slideshare.net/spraints/overview-of-source-control-systemskey
Editor's Notes
- 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&#x2019;ll pull in Windows stuff that I know about.
- in ancient times, there was SCCS.
- &#x201C;revision control system&#x201D; 1982 (man1) - 1995 (wikipedia)
- revisions are tracked in a &#x201C;,v&#x201D; 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 &#x201C;elements&#x201D; -- 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 &#x201C;snapshot&#x201D; -- 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 &#x201C;config spec&#x201D; tells the server the rules to follow when showing you files.
- when you branch in clearcase, like in RCS or CVS, it&#x2019;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 &#x201C;arrows&#x201D;. 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.
- &#x201C;more than meets the eye&#x201D; 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&#x2019;s essential), and easy to back out of at any point. i&#x2019;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&#x2019;s hard to share code between uncompleted features * CI is harder (unless you&#x2019;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&#x2019;re using git)
- if you&#x2019;re dealing with branches, and the branch has conflicts (or it&#x2019;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&#x2019;t matter quite as much, but the merge back is TRIVIAL).
- why is merging easier with git? an example might help
- when you &#x201C;add&#x201D; a file to git&#x2019;s index, it makes a blob, with a sha1 hash of the file&#x2019;s contents.
- when you check in your index&#x2019;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&#x2019;t store another copy of the file, but makes a new tree and a new commit.
- Let&#x2019;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 &#x201C;other&#x201D; 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 &#x201C;fast forward&#x201D; merge, which basically means it just moves where the name &#x201C;master&#x201D; points.