Lecture07 Version Control
Transcript of Lecture07 Version Control
-
8/12/2019 Lecture07 Version Control
1/48
Prof. Aiken CS 169 Lecture 7 1
Version Control
CS169
Lecture 7
-
8/12/2019 Lecture07 Version Control
2/48
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
-
8/12/2019 Lecture07 Version Control
3/48
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
-
8/12/2019 Lecture07 Version Control
4/48
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
-
8/12/2019 Lecture07 Version Control
5/48
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 . . .
-
8/12/2019 Lecture07 Version Control
6/48
Prof. Aiken CS 169 Lecture 7 6
Scenario I: Bug Fix
TimeReleas
es1.0
First public releaseof the hot newproduct
-
8/12/2019 Lecture07 Version Control
7/48
Prof. Aiken CS 169 Lecture 7 7
Scenario I: Bug Fix
1.0
TimeReleas
es
Internal developmentcontinues,progressing to version1.3
1.3
-
8/12/2019 Lecture07 Version Control
8/48
Prof. Aiken CS 169 Lecture 7 8
Scenario I: Bug Fix
1.0
TimeReleases
A fatal bug isdiscovered in theproduct (1.0), but 1.3is not stable enough
to release. Solution:Create a versionbased on 1.0 with thebug fix.
1.3
1.0bugfix
-
8/12/2019 Lecture07 Version Control
9/48
Prof. Aiken CS 169 Lecture 7 9
Scenario I: Bug Fix
1.0
TimeReleases
Note that there arenow two lines ofdevelopmentbeginning at 1.0.
This is branching.1.3
1.0bugfix
-
8/12/2019 Lecture07 Version Control
10/48
Prof. Aiken CS 169 Lecture 7 10
Scenario I: Bug Fix
1.0
TimeReleases
The bug fix shouldalso be applied to themain code line so thatthe next productrelease has the fix.
1.3
1.0bugfix
1.4
-
8/12/2019 Lecture07 Version Control
11/48
Prof. Aiken CS 169 Lecture 7 11
Scenario I: Bug Fix
1.0
TimeReleases
Note that twoseparate lines ofdevelopment comeback together in 1.4.
This is mergingor
updating.1.3
1.0bugfix
1.4
-
8/12/2019 Lecture07 Version Control
12/48
Prof. Aiken CS 169 Lecture 7 12
Scenario II: Normal Development
1.5
TimeReleases
You are in the middleof a project withthree developersnamed a, b, and c.
-
8/12/2019 Lecture07 Version Control
13/48
Prof. Aiken CS 169 Lecture 7 13
Scenario II: Normal Development
1.5
TimeReleases
At the beginning ofthe day everyonechecks outa copy ofthe code.
A check out is a local
working copy of aproject, outside ofthe version controlsystem. Logically it isa (special kind of)
branch.
1.5a
1.5b
1.5c
-
8/12/2019 Lecture07 Version Control
14/48
Prof. Aiken CS 169 Lecture 7 14
Scenario II: Normal Development
1.5
TimeReleases
The local versionsisolate the developersfrom each otherspossibly unstablechanges. Each builds
on 1.5, the mostrecent stable version.
1.5a
1.5b
1.5c
-
8/12/2019 Lecture07 Version Control
15/48
Prof. Aiken CS 169 Lecture 7 15
Scenario II: Normal Development
1.5
TimeReleases
1.5a
1.5b
1.5c
1.6
At 4:00 pm everyonechecks intheir testedmodifications. Acheck in is a kind ofmerge where local
versions are copiedback into the versioncontrol system.
-
8/12/2019 Lecture07 Version Control
16/48
Prof. Aiken CS 169 Lecture 7 16
Scenario II: Normal Development
1.5
TimeReleases
1.5a
1.5b
1.5c
1.6
In many organizationscheck in automaticallyruns a test suiteagainst the result ofthe check in. If the
tests fail the changesare not accepted.
This prevents asloppy developer fromcausing all work to
stop by, e.g., creatinga version of thesystem that does notcompile.
-
8/12/2019 Lecture07 Version Control
17/48
Prof. Aiken CS 169 Lecture 7 17
Scenario III: Debugging
1.5
TimeReleases
1.6
You develop asoftware systemthrough severalrevisions.
1.7
-
8/12/2019 Lecture07 Version Control
18/48
Prof. Aiken CS 169 Lecture 7 18
Scenario III: Debugging
1.5
TimeReleases
1.6
In 1.7 you suddenlydiscover a bug hascrept into thesystem. When was itintroduced?
With version controlyou can check out oldversions of thesystem and see whichrevision introducedthe bug.
1.7
-
8/12/2019 Lecture07 Version Control
19/48
Prof. Aiken CS 169 Lecture 7 19
Scenario IV: Libraries
TimeReleases
You are buildingsoftware on top of athird-party library,for which you have
source.
Library A
-
8/12/2019 Lecture07 Version Control
20/48
Prof. Aiken CS 169 Lecture 7 20
Scenario IV: Libraries
TimeReleases
Library A
You beginimplementation of
your software,including
modifications to thelibrary.
0.7
-
8/12/2019 Lecture07 Version Control
21/48
Prof. Aiken CS 169 Lecture 7 21
Scenario IV: Libraries
TimeReleases
Library A 0.7
Library B
A new version of thelibrary is released.Logically this is abranch: library
development hasproceededindependently of yourown development.
-
8/12/2019 Lecture07 Version Control
22/48
Prof. Aiken CS 169 Lecture 7 22
Scenario IV: Libraries
TimeReleases
Library A
You merge the newlibrary into the maincode line, therebyapplying your
modifications to thenew library version.
0.7
Library B
0.8
-
8/12/2019 Lecture07 Version Control
23/48
Prof. Aiken CS 169 Lecture 7 23
Concepts
Projects
Revisions
Branches
Merging
Conflicts
-
8/12/2019 Lecture07 Version Control
24/48
Prof. Aiken CS 169 Lecture 7 24
Projects
Aprojectis a set of files in version control Called a modulein 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
-
8/12/2019 Lecture07 Version Control
25/48
Prof. Aiken CS 169 Lecture 7 25
Assumption
Consider a project with 1 file
We will return to the multiple file case later
-
8/12/2019 Lecture07 Version Control
26/48
-
8/12/2019 Lecture07 Version Control
27/48
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
-
8/12/2019 Lecture07 Version Control
28/48
-
8/12/2019 Lecture07 Version Control
29/48
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
-
8/12/2019 Lecture07 Version Control
30/48
Prof. Aiken CS 169 Lecture 7 30
Merging
Start with a file, say 1.5
Bob makes changes A to1.5
Alice makes changes B to1.5
Assume Alice checks in first Current revision is 1.6 = apply(B,1.5)
-
8/12/2019 Lecture07 Version Control
31/48
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 currentversion!
The system complains
Bob is told to updatehis local copy of the code
-
8/12/2019 Lecture07 Version Control
32/48
Prof. Aiken CS 169 Lecture 7 32
Merging (Cont.)
Bob does an update This applies Alices changes Bto Bobs code
Remember Bobs code isapply(A,1.5)
Two possible outcomes of an update Success
Conflicts
-
8/12/2019 Lecture07 Version Control
33/48
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)
-
8/12/2019 Lecture07 Version Control
34/48
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
-
8/12/2019 Lecture07 Version Control
35/48
Prof. Aiken CS 169 Lecture 7 35
Conflicts
Arise when two programmers edit the samepiece 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 socomplains of a conflict.
-
8/12/2019 Lecture07 Version Control
36/48
Prof. Aiken CS 169 Lecture 7 36
Conflicts (Cont.)
System cannot apply changes when there areconflicts 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
-
8/12/2019 Lecture07 Version Control
37/48
-
8/12/2019 Lecture07 Version Control
38/48
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
-
8/12/2019 Lecture07 Version Control
39/48
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 . . .
-
8/12/2019 Lecture07 Version Control
40/48
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
-
8/12/2019 Lecture07 Version Control
41/48
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
-
8/12/2019 Lecture07 Version Control
42/48
Prof. Aiken CS 169 Lecture 7 42
PRCS Model (Cont.)
Changes to individual files treated as changesto the project
Every state of the project has a name E.g., 1.6
Makes it possible to recover any point in theproject history
-
8/12/2019 Lecture07 Version Control
43/48
Prof. Aiken CS 169 Lecture 7 43
CVS Model
Operations are on files
Example
Check out Modify foo.barrevision 2.7
Check in
foo.barnow revision 2.8
-
8/12/2019 Lecture07 Version Control
44/48
Prof. Aiken CS 169 Lecture 7 44
CVS Model (Cont.)
CVS knows foo.barchanged Version 2.7modified to 2.8
But CVS does not know the state of the restof the project when foo.barchanged No correlation kept with other files
Hard to reconstruct every state of the project And in some cases, impossible
-
8/12/2019 Lecture07 Version Control
45/48
Prof. Aiken CS 169 Lecture 7 45
CVS Tags
Some operations require a snapshot of theglobal project state Branching
Major releases
CVS can taga project with a name A separate operation to do what PRCS does for
every change
-
8/12/2019 Lecture07 Version Control
46/48
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
-
8/12/2019 Lecture07 Version Control
47/48
-
8/12/2019 Lecture07 Version Control
48/48
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