1. CS 438 “...Goals: Time Travel, Parallel Universes...”
Source Control Oct 01, 2008
Nathaniel Filardo
Dave Eckhardt
Roger Dannenberg
Zach Anderson (S '03)
L11b_PRCS

2. Synchronization Project 1 was due Monday Success rate: Two handins.
Four late day requests.
Lots of protocol violations in the whole mess.
What went wrong?
Other than “I didn't start early enough”
Is there something ... should know? I?
You?
Future me-s?
Future you-s?

3. Synchronization Project 2 went out Monday
Have you read the handouts yet?
Have you downloaded the tarball yet?
Failure to do both of these TONIGHT stands a very good chance of wrecking your grade.
There is no chance for a break between now and then, sorry.
This is all as specified last week.
It is due on the 15th.
This is a two week assignment because it needs to be.

4. Promised Future Synchronization
Project 2 Checkpoint
“startle” test for thr_create()
Is now a scheduled event:
On Wednesday, Oct 8, class will meet in the ugrad lab (NEB 2xx)
You will be required to demonstrate that your thread library can pass the “startle” program.
Both partners ARE REQUIRED TO attend.
This is going to be worth 10% of your P2 grade.
This is boolean (0/10), or perhaps tristate (0/5/10).
Late days are not usable on this checkpoint.
This checkpoint is IN PERSON.
transcripts of success will not be accepted if no effort at a live presentation is made.

5. Outline Motivation Repository vs. Working Directory
Conflicts and Merging
Branching
A Brief Introduction to git

6. Goals Working together should be easy Time travel
Useful for challenging patents
Very useful for reverting from a sleepless hack session
Parallel universes
Experimental universes
Product-support universes

7. Goal: Shared Workspace
Reduce development latency via parallelism
[But: Brooks, Mythical Man-Month]
Alice
Bob
awesome.c
Charlie
Devon

8. Goal: Time Travel Retrieving old versions should be easy.
Once Upon A Time…
Alice: What happened to the code? It doesn’t work.
Charlie: Oh, I made some changes. My code is 1337!
Alice: Rawr! I want the code from last Tuesday!

9. Goal: Parallel Universes
Safe process for implementing new features.
Develop bell in one universe
Develop whistle in another
Don't inflict B's core dumps on W
Eventually produce bell-and-whistle release

10. How? Keep a global repository for the project.
Maybe even more than one? (wait, what?)

11. The Repository Version / Revision / Configuration Project Repository
Contents of some files at a particular point in time
aka “Snapshot”
Project
A “sequence” of versions
(not really)
Repository
Directory where projects are stored

12. The Repository Stored in group-accessible location
Old way: file system
Modern way: “repository server”
Versions in repository visible group-wide
Whoever has read access
“Commit access” often separate

13. How? Keep a global repository for the project.
Each user keeps a working directory.

14. The Working Directory Many names (“sandbox”) Where revisions happen
Typically belongs to one user
Versions are checked out to here
New versions are checked in from here

15. How? Keep a global repository for the project.
Each user keeps a working directory.
Concepts of checking out, and checking in

16. Checking Out. Checking In.
A version is copied from the repository
Typically “Check out the latest”
Or: “Revision 3.1.4”, “Yesterday noon”
Work
Edit, add, remove, rename files
Checking in
Working directory ⇒ repository atomically
Result: new version

17. Checking Out. Checking In.
Repository
Working Directory
v0.1
v0.1 copy
v0.1
check out

18. Checking Out. Checking In.
Repository
Working Directory
v0.1
v0.1 copy
v0.1
mutate
v0.1++

19. Checking Out. Checking In.
Repository
Working Directory
v0.1
v0.1
v0.2
v0.1++
v0.2
check in

20. How? Keep a global repository for the project.
Each user keeps a working directory.
Concepts of checking out, and checking in
Mechanisms for merging

21. Conflicts and Merging Two people check out. Both modify foo.c
Each wants to check in a new version.
Whose is the correct new version?

22. Conflicts and Merging Conflict Independent changes which “overlap”
Textual overlap detected by revision control
Semantic conflict cannot be
Merge displays conflicting updates per file
Pick which code goes into the new version
A, B, NOTA
Story now, real-life example later

23. Alice Begins Work
Alice
Repository
Bob
v0.2
copy
v0.2
v0.2
fix b#1

24. Bob Arrives, Checks Out v0.2 copy v0.2 v0.2 copy v0.2 fix b#1 Alice
Repository
Bob
v0.2
copy
v0.2
v0.2
copy
v0.2
fix b#1

25. Alice Commits, Bob Has Coffee
Repository
Bob
v0.2
copy
v0.2
v0.2
copy
v0.2
fix b#1
v0.3

26. Bob Fixes Something Too
Alice
Repository
Bob
v0.2
copy
v0.2
v0.2
copy
v0.2
fix b#1
v0.3
v0.2
fix b#7

27. Wrong Outcome v0.2 copy v0.2 v0.2 copy v0.2 fix b#1 v0.3 v0.3 v0.2
Alice
Repository
Bob
v0.2
copy
v0.2
v0.2
copy
v0.2
fix b#1
v0.3
v0.3
v0.2
fix b#7

28. “Arguably Less Wrong” v0.2 copy v0.2 v0.2 copy v0.2 fix b#1 v0.3 v0.2
Alice
Repository
Bob
v0.2
copy
v0.2
v0.2
copy
v0.2
fix b#1
v0.3
v0.2
fix b#7
v0.4

29. Merge, Bob, Merge! v0.2 copy v0.2 v0.2 copy v0.2 fix b#1 v0.3 v0.2
Alice
Repository
Bob
v0.2
copy
v0.2
v0.2
copy
v0.2
fix b#1
v0.3
v0.2
fix b#7
fix b#1
fix b#7

30. Committing Genuine Progress
Alice
Repository
Bob
v0.2
copy
v0.2
v0.2
copy
v0.2
fix b#1
v0.3
v0.2
fix b#7
v0.4
fix b#1
fix b#7

31. How? Keep a global repository for the project.
Each user keeps a working directory.
Concepts of checking out, and checking in
Mechanisms for merging
Mechanisms for branching

32. Branching A branch is a sequence of versions (not really...)
Changes on one branch don't affect others
Project may contain many branches
Why branch?
Implement a new “major” feature
Begin a temporary independent sequence of development

33. Branching
The actual branching and merging take place in a particular user's working directory, but this is what such a sequence would look like to the repository.
branch
v0.3
v1.1
v0.37
v1.42
merge
v1.43

34. Branch Life Cycle “The Trunk” “Release 1.0”, “Release 2.0”, ...
Release 1.0 maintenance branch
After 1.0: 1.0.1, 1.0.2, ...
Bug-fix updates as long as 1.0 has users
Internal development branches
1.1.1, 1.1.2, ...
Probably client, server

35. Branch Life Cycle “Development excursion” branch model
Create branch to fix bug #99 in v1.1
One or more people make 7 changes
Branch “collapses” back to trunk
Merge 1.1.bug99.7 against
Result:
There will be no 1.1.bug99.8
In some systems, there can't be

36. Branch Life Cycle “Controlled isolation” branch model
Server people work on 1.3.server
Fix server code
Run stable client test suite vs. new server
Client people work on 1.3.client
Fix client code
Run new client test suite vs. stable server
Note
Branches do not collapse after one merge!

37. Branch Life Cycle “Controlled isolation” branch model
Periodic merges - example
1.3.server.45, ⇒
1.3.client.112, ⇒
Each group can keep working while one person “pushes up” a version to the parent
When should server team “pull down” changes?
1.3.server.47, ⇒ 1.3.server.48?
1.3.server.99, ⇒ 1.3.server.100?
Efficiency now vs. merge cost later...

38. Branch Life Cycle Successful development branch Merged back to parent
No further versions
Unsuccessful development branch
Some changes pulled out?
Maintenance branch
“End of Life”: No further versions

39. Are Branches Deleted? Consider the repository “data structure”
Revisions of each file (coded as deltas)
Revisions of the directory tree
Branch delete
Complicated data structure update
[Not a well-tested code path]
Generally a bad idea
History could always be useful later...

40. Source Control Opinions
CVS
very widely used
mature, lots of features
default behavior often wrong
OpenCM
security-conscious design
not widely used
BitKeeper
Favored by Linus Torvalds
“Special” license restrictions
SubVersion (svn)
SVN > CVS (design)
SVN > CVS (size)
Doesn't work in AFS
Yes, it does
No, it doesn't?
PerForce
commercial
reasonable design
works well (enough)
big server

41. Source Control Opinions
Popular DVCSes:
Mercurial (“hg”)
Bazaar (“bzr”)
git
Recently revamped
Generally...
Quite annoyingly limited
Data structure uber alles!
All merges total!
Poor cherrypicking.
But widely used, so...
Less popular DVCSes:
Arch / TLA
Monotone
Certs everywhere
Darcs
patch algebra
These...
Interesting theories
Less wildly popular

42. Dave (and nwf)'s Raves CVS Many commercial products
Commit: atomic if you are careful
Named snapshots: if you are careful
Branching: works if you are careful
Core operations require care & expertise!!!
Many commercial products
Require full-time person, huge machine
Punitive click-click-click GUI
Poor understanding of data structure requirements

43. Recommendation for CS 438 You can use CVS if you're used to it Try git
Also: SVN, hg, darcs, ...
If you are overwhelmed with choice...
Try git
It's a reasonably nice distributed version control system.
But stay away from the “advanced” stuff.

44. Getting Started Git is already installed on all supported systems!
Or you can install it yourself on your own.
I am not a git expert.
I cannot debug your setups!

45. Distributed? What's this “distributed” nonsense?
Every checkout is also a repository
With complete copies of history?
Every checkout is also a branch
Woah, that's funky.
If you're used to CVS or SVN, this is very, very strange.
It's also not quite the same as the story I just told you.
We'll talk about a workflow model briefly

46. Creating A New Project Anywhere, but probably in a blank directory:
$ git init
Creates a directory .git
Contains a hash-tree of all entities ever seen by the version control system.
Also contains things like config, heads, remotes, and other goodies.

47. Populating the world Adding Files $ git add file1 file2 ...
To add every file in a directory
$ git add dir/
Rarely what you want!!!
These are “staged” operations...
You must commit before they take effect.
Much like editing files!

48. Checking In Commit Yourself! $ git commit
Fires up your $EDITOR and asks you for commentary.
Can restrict which files on the command line, or even use --interactive.
Creates a new LOCAL revision.
Your partner has no idea that this has happened.

49. Sharing Your Work Ok, so how do changes ever become non-local? Pull
$ git pull [remote path]
Pulls changes from the remote path into the local repository.
Git has a notion of “default remote”
Push
$ git push [remote path]
Pushes changes from the local repo into the remote.

50. Checking Out A Project Making a new checkout:
$ git clone remote [local]
Clones the remote repository
All set for you to work in.
The default push/pull target is the remote you copied.
You can use this mechanism to branch, if you so desire.
Git also has built-in support for named branches
See “man git-branch” or any of the other docs.

51. Conflicts and Merging Suppose this file is in the repository:
Named hello.c
#include <stdlib.h>
#include <stdio.h>
int main(void) {
printf("Hello World!\n");
return 0; }

52. Conflicts and Merging
Suppose Alice and Charlie check out this version, and make changes:
Alice's Version
Charlie's Version
#include <stdlib.h>
#include <stdio.h>
#define SUPER 0
int main(void) {
/* prints "Hello World"
to stdout */
printf("Hello World!\n");
return SUPER; }
#include <stdlib.h>
#include <stdio.h>
int main(void) {
/* this, like, says
hello, and stuff */
printf("Hello Hercules!\n");
return 42; }

53. Conflicts and Merging Suppose Alice checks in first
$ git commit && git push
Now Charlie must perform a merge
$ git commit && git pull && git push ⇒ will fail while pulling
$ git merge
Default merge option performs a CVS-like merge.
$ git push ⇒ should work now

54. Merge Mutilation There wasn't a conflict “here”
Conflicts are entirely textual!
#include <stdlib.h>
#include <stdio.h>
#define SUPER 0
int main(void) {
<<<<<<<< HEAD:hello.c
/* this, like, says hello, and stuff */
printf("Hello Hercules!");
return 42;
========
/* prints "Hello World" to stdout */
printf("Hello World!");
return SUPER;
>>>>>>>> abcd5656efef ab:hello.c }
commit:file name
Division between
conflicting commits
Aren't commit identifiers lovely?

55. Conflicts and Merging Pick/create the desired version
Check that into the repository.
Label it helpfully.

56. Branching To create the first version of a new branch:
$ git branch Experimental_VM
$ git checkout Experimental_VM
To merge master with branch:
$ git checkout master
$ git merge Experimental_VM

57. Information To get a summary of changes: $ git status
To ask about changes in the past:
$ git log

58. Suggested Work Flow For NFS
DVCSes have 2**31 flavors of work flow.
Since we only have NFS and no ACLs...
Life is pain and suffering (I miss PTS & AFS)
Each partner makes an “export” repository
This regretfully has to be world readable, but not writable.
Please don't look at other people's repositories.
That's grounds for the disciplinary committee to get involved and nobody wants that.
Each partner clones their export repository to do work and pushes back locally.
Each partner pulls from the other's “export” directory, too.

59. Suggested Work Flow for NFS
Directories:
~alice/cs438/export
~muzappa/cs438/export
Alice's setup:
$ git clone ~alice/cs438/export working
Alice's day:
$ cd working
$ git pull ~muzappa/cs438/export HEAD
[work, commit, work, , commit, pull]
$ git commit
$ git push ## to ~alice/cs438/export
git init these

60. Suggestions Develop a convention for commit logs When to branch?
Type of revision(bug-fix, commenting, etc.)
Meaningful, short descriptions
When to branch?
Bug fixing?
Check out, fix, check in to same branch
Trying COW fork since regular fork works?
Branching probably a good idea.
“Any time you want commits kept secret”

61. Suggestions Commit early & Commit often
“Never” pull with outstanding changes.
Workflow for “I wish I had Bob's changes” :
Commit all local changes in one or more commits.
Pull from Bob
This will attempt any automagic merge operations.
Carry out conflict resolution, if any.
Commit immediately after resolving conflicts.
Go back to work.
The really paranoid may separate automatic and manual conflict resolution steps, too.
Commit ; pull ; commit ; resolve ; commit

62. Suggestions The DVCS nature of git makes backups really easy
Just push occasionally!
There's no excuse for not having one!
Git may eat your files!
Having a backup is always a good idea.
You may eat your files!
rm -rf dir/
Oh that was the repository, too!

63. Some other features of git
Reset
Throws away the working directory state.
Tags
Let you label revisions with useful names.
Maybe “I pass test X” or “version” labels?
Gitk
Graphical revision history viewer
Rebase, rerere, octopus merge, ...
These are probably “too advanced”
You probably won't need them.

64. Summary We can now: See GIT documentation Create projects
Check source in/out
Merge, and
Branch
See GIT documentation
There's a lot out there.
“gittutorial” is a good place to start