Prof.

Aiken CS 169 Lecture 7 1

Version Control
CS169
Lecture 7
Prof. Aiken CS 169 Lecture 7 2
Outline
What is version control?
And why use it?
Scenarios

Basic concepts
Projects
Branches
Merging
conflicts

Two systems
PRCS
CVS
Prof. Aiken CS 169 Lecture 7 3
All Software Has Multiple Versions
Different releases of a product

Variations for different platforms
Hardware and software

Versions within a development cycle
Test release with debugging code
Alpha, beta of final release

Each time you edit a program



Prof. Aiken CS 169 Lecture 7 4
Version Control
Version control tracks multiple versions

In particular, allows
old versions to be recovered
multiple versions to exist simultaneously
Prof. Aiken CS 169 Lecture 7 5
Why Use Version Control?
Because everyone does
A basic software development tool

Because it is useful
You will want old/multiple versions
Without version control, cant recreate project history

Because we require it
For your own good
The only such requirement in the course . . .
Prof. Aiken CS 169 Lecture 7 6
Scenario I: Bug Fix
Time
R
e
l
e
a
s
e
s

1.0
First public release
of the hot new
product
Prof. Aiken CS 169 Lecture 7 7
Scenario I: Bug Fix
1.0
Time
R
e
l
e
a
s
e
s

Internal development
continues,
progressing to version
1.3
1.3
Prof. Aiken CS 169 Lecture 7 8
Scenario I: Bug Fix
1.0
Time
R
e
l
e
a
s
e
s

A fatal bug is
discovered in the
product (1.0), but 1.3
is not stable enough
to release. Solution:
Create a version
based on 1.0 with the
bug fix.
1.3
1.0
bugfix
Prof. Aiken CS 169 Lecture 7 9
Scenario I: Bug Fix
1.0
Time
R
e
l
e
a
s
e
s

Note that there are
now two lines of
development
beginning at 1.0.
This is branching.
1.3
1.0
bugfix
Prof. Aiken CS 169 Lecture 7 10
Scenario I: Bug Fix
1.0
Time
R
e
l
e
a
s
e
s

The bug fix should
also be applied to the
main code line so that
the next product
release has the fix.
1.3
1.0
bugfix
1.4
Prof. Aiken CS 169 Lecture 7 11
Scenario I: Bug Fix
1.0
Time
R
e
l
e
a
s
e
s

Note that two
separate lines of
development come
back together in 1.4.
This is merging or
updating.
1.3
1.0
bugfix
1.4
Prof. Aiken CS 169 Lecture 7 12
Scenario II: Normal Development
1.5
Time
R
e
l
e
a
s
e
s

You are in the middle
of a project with
three developers
named a, b, and c.
Prof. Aiken CS 169 Lecture 7 13
Scenario II: Normal Development
1.5
Time
R
e
l
e
a
s
e
s

At the beginning of
the day everyone
checks out a copy of
the code.
A check out is a local
working copy of a
project, outside of
the version control
system. Logically it is
a (special kind of)
branch.
1.5a
1.5b
1.5c
Prof. Aiken CS 169 Lecture 7 14
Scenario II: Normal Development
1.5
Time
R
e
l
e
a
s
e
s

The local versions
isolate the developers
from each others
possibly unstable
changes. Each builds
on 1.5, the most
recent stable version.
1.5a
1.5b
1.5c
Prof. Aiken CS 169 Lecture 7 15
Scenario II: Normal Development
1.5
Time
R
e
l
e
a
s
e
s

1.5a
1.5b
1.5c
1.6
At 4:00 pm everyone
checks in their tested
modifications. A
check in is a kind of
merge where local
versions are copied
back into the version
control system.
Prof. Aiken CS 169 Lecture 7 16
Scenario II: Normal Development
1.5
Time
R
e
l
e
a
s
e
s

1.5a
1.5b
1.5c
1.6
In many organizations
check in automatically
runs a test suite
against the result of
the check in. If the
tests fail the changes
are not accepted.
This prevents a
sloppy developer from
causing all work to
stop by, e.g., creating
a version of the
system that does not
compile.
Prof. Aiken CS 169 Lecture 7 17
Scenario III: Debugging
1.5
Time
R
e
l
e
a
s
e
s

1.6
You develop a
software system
through several
revisions.
1.7
Prof. Aiken CS 169 Lecture 7 18
Scenario III: Debugging
1.5
Time
R
e
l
e
a
s
e
s

1.6
In 1.7 you suddenly
discover a bug has
crept into the
system. When was it
introduced?

With version control
you can check out old
versions of the
system and see which
revision introduced
the bug.
1.7
Prof. Aiken CS 169 Lecture 7 19
Scenario IV: Libraries
Time
R
e
l
e
a
s
e
s

You are building
software on top of a
third-party library,
for which you have
source.
Library A
Prof. Aiken CS 169 Lecture 7 20
Scenario IV: Libraries
Time
R
e
l
e
a
s
e
s

Library A
You begin
implementation of
your software,
including
modifications to the
library.
0.7
Prof. Aiken CS 169 Lecture 7 21
Scenario IV: Libraries
Time
R
e
l
e
a
s
e
s

Library A 0.7
Library B
A new version of the
library is released.
Logically this is a
branch: library
development has
proceeded
independently of your
own development.
Prof. Aiken CS 169 Lecture 7 22
Scenario IV: Libraries
Time
R
e
l
e
a
s
e
s

Library A
You merge the new
library into the main
code line, thereby
applying your
modifications to the
new library version.
0.7
Library B
0.8
Prof. Aiken CS 169 Lecture 7 23
Concepts
Projects
Revisions
Branches
Merging
Conflicts
Prof. Aiken CS 169 Lecture 7 24
Projects
A project is a set of files in version control
Called a module in CVS

Version control doesnt care what files
Not a build system
Or a test system
Though there are often hooks to these other systems
Just manages versions of a collection of files
Prof. Aiken CS 169 Lecture 7 25
Assumption
Consider a project with 1 file

We will return to the multiple file case later
Prof. Aiken CS 169 Lecture 7 26
Revisions
Consider
Check out a file
Edit it
Check the file back in

This creates a new version of the file
Usually increment minor version number
E.g., 1.5 -> 1.6
Prof. Aiken CS 169 Lecture 7 27
Revisions (Cont.)
Observation: Most edits are small

For efficiency, dont store entire new file
Store diff with previous version
Minimizes space
Makes check-in, check-out potentially slower
Must apply diffs from all previous versions to compute
current file

Prof. Aiken CS 169 Lecture 7 28
Revisions (Cont.)
With each revision, system stores
The diffs for that version
The new minor version number
Other metadata
Author
Time of check in
Log file message
Results of smoke test


Prof. Aiken CS 169 Lecture 7 29
Branches
A branch is just two revisions of a file
Two people check out 1.5
Check in 1.5.1
Check in 1.5.2

Notes
Normally checking in does not create a branch
Changes merged into main code line
Must explicitly ask to create a branch
Prof. Aiken CS 169 Lecture 7 30
Merging
Start with a file, say 1.5

Bob makes changes A to 1.5

Alice makes changes B to 1.5

Assume Alice checks in first
Current revision is 1.6 = apply(B,1.5)
Prof. Aiken CS 169 Lecture 7 31
Merging (Cont.)
Now Bob checks in
System notices that Bob checked out 1.5
But current version is 1.6
Bob has not made his changes in the current
version!

The system complains
Bob is told to update his local copy of the code
Prof. Aiken CS 169 Lecture 7 32
Merging (Cont.)
Bob does an update
This applies Alices changes B to Bobs code
Remember Bobs code is apply(A,1.5)

Two possible outcomes of an update
Success
Conflicts
Prof. Aiken CS 169 Lecture 7 33
Success
Assume that
apply(A,apply(B,1.5) = apply(B,apply(A,1.5))

Then then order of changes didnt matter
Same result whether Bob or Alice checks in first
The version control system is happy with this

Bob can now check in his changes
Because apply(B,apply(A,1.6)) = apply(B,1.6)
Prof. Aiken CS 169 Lecture 7 34
Failure
Assume
apply(A,apply(B,1.5) apply(B,apply(A,1.6))

There is a conflict
The order of the changes matters
Version control will complain
Prof. Aiken CS 169 Lecture 7 35
Conflicts
Arise when two programmers edit the same
piece of code
One change overwrites another

1.5: a = b;
Alice: a = b++;
Bob: a = ++b;

The system doesnt know what should be done, and so
complains of a conflict.


Prof. Aiken CS 169 Lecture 7 36
Conflicts (Cont.)
System cannot apply changes when there are
conflicts
Final result is not unique
Depends on order in which changes are applied

Version control shows conflicts on update
Generally based on diff3

Conflicts must be resolved by hand


Prof. Aiken CS 169 Lecture 7 37
Conflicts are Syntactic
Conflict detection is based on nearness of
changes
Changes to the same line will conflict
Changes to different lines will likely not conflict

Note: Lack of conflicts does not mean Alices
and Bobs changes work together
Prof. Aiken CS 169 Lecture 7 38
Example With No Conflict
Revision 1.5: int f(int a, int b) { }

Alice: int f(int a, int b, int c) { }
add argument to all calls to f

Bob: add call f(x,y)

Merged program
Has no conflicts
But will not even compile
Prof. Aiken CS 169 Lecture 7 39
Dont Forget
Merging is syntactic

Semantic errors may not create conflicts
But the code is still wrong
You are lucky if the code doesnt compile
Worse if it does . . .
Prof. Aiken CS 169 Lecture 7 40
Two Systems
We discuss
CVS
De facto free software standard for version control
PRCS
Hilfinger, et al.

For single file projects, these are the same
Except for administration


Prof. Aiken CS 169 Lecture 7 41
PRCS Model
Operations are on the project
Not on individual files

Example
Project version 1.5
Check out
Update file foo.bar
Check in
Project version is now 1.6
Prof. Aiken CS 169 Lecture 7 42
PRCS Model (Cont.)
Changes to individual files treated as changes
to the project

Every state of the project has a name
E.g., 1.6

Makes it possible to recover any point in the
project history
Prof. Aiken CS 169 Lecture 7 43
CVS Model
Operations are on files

Example
Check out
Modify foo.bar revision 2.7
Check in
foo.bar now revision 2.8

Prof. Aiken CS 169 Lecture 7 44
CVS Model (Cont.)
CVS knows foo.bar changed
Version 2.7 modified to 2.8

But CVS does not know the state of the rest
of the project when foo.bar changed
No correlation kept with other files
Hard to reconstruct every state of the project
And in some cases, impossible
Prof. Aiken CS 169 Lecture 7 45
CVS Tags
Some operations require a snapshot of the
global project state
Branching
Major releases

CVS can tag a project with a name
A separate operation to do what PRCS does for
every change

Prof. Aiken CS 169 Lecture 7 46
Administration
PRCS has a simple administrative model
One file with all metadata in a standard format
Really, a small project programming language
Administration done by text editing
The administrative file is under version control, too
Get old project versions by checking out old admin files

CVS administration is much more complex
Numerous files, information scattered throughout
One admin file per file under CVS
Makes renaming, moving files awkward
Prof. Aiken CS 169 Lecture 7 47
Design
Version control of projects is about snapshots
of sets of files
PRCS represents this directly
CVS is oriented toward individual files
And it shows in complexity

A lesson here for those interested in
software design . . .
Prof. Aiken CS 169 Lecture 7 48
Trade-offs
CVS has many more features than PRCS
In particular, remote repositories
Allows distributed work over ssh

If you dont need remote check in/check out,
PRCS may be a better choice