/2012

254

21/09/

Quality AssuranceVersion Control 1

SO

FTE

NG

Version Control 1

eala

nd Part II - Lecture 6

klan

d | N

ew Z

eve

rsity

of A

uck

The

Uni

v

1

Today’s Outline/2012

y 2

5421/09/

• Version ControlM i C

SO

FTE

NG

• Managing Concurrency

eala

ndkl

and

| New

Ze

vers

ity o

f Auc

kTh

e U

niv

2

/2012

254

21/09/

SO

FTE

NG

Version Control

eala

nd

Version Control

Have always

klan

d | N

ew Z

e Have always used version

control

vers

ity o

f Auc

k

Has never used version

The

Uni

v

3control

Version Control/2012

Common problems in a software project:

254

21/09/

p p j– A change needs to be undone– Old code that was overwritten would be useful again

SO

FTE

NG

– Several developers work on the same program part simultaneouslyH d I t th l t t i f th d ?

eala

nd

– How do I get the latest version of the code?

The solution: a Version Control System (VCS)

klan

d | N

ew Z

e The solution: a Version Control System (VCS)– Manages a common repository for all artefacts– Controls concurrent access

vers

ity o

f Auc

k Controls concurrent access– Creates new version for each change (redo/undo

possible)

The

Uni

v

4

p )– Helps to merge several contributions to same part

Version Control System/2012

yNetwork

254

21/09/

WorkingCopy

Repository

SO

FTE

NG

WorkingCopy

Repository

Version 4Version 5

eala

nd

Working

Copy

Version 1Version 2

Version 3Version 4

klan

d | N

ew Z

e WorkingCopy

Version 1

vers

ity o

f Auc

k

• Developers work on their local working copies• Developers synchronize their working copy with the repository• Repository usually uses delta encoding for the versions

The

Uni

v

5

• Repository usually uses delta encoding for the versions• Two ways to avoid conflicts: locking and merging

Product Space and V rsi n Sp c

/2012

Version SpaceProduct space: What is versioned? How is the data organized?

254

21/09/ • Just files: each file has a version number which is increased

when the file is changed (e.g. CVS)• Files and folders: the whole file-folder structure has a single

SO

FTE

NG

gversion number which is increased for any change done to any file/folder (e.g. SVN)

• Other data models, e.g. PD model in PDStore (instances, links)

eala

nd

Other data models, e.g. PD model in PDStore (instances, links)

Version Space: How is it versioned? How are versions organized?• Version identifiers:

klan

d | N

ew Z

e

e.g. serial numbers (1, 2, 3, …), dates (e.g. 20060901), …• Version history:

• How are versions ordered? Parent-version / child-version

vers

ity o

f Auc

k How are versions ordered? Parent version / child version• Versions with several parents? -> Merging• Versions with several children? -> Branching

The

Uni

v

6

Delta Encoding/2012

g• Storing every version of a file takes up a lot space• Idea: just store differences between versions

254

21/09/ Idea: just store differences between versions

• Differences (”deltas” / “diffs”) can be calculated automatically with various algorithms

SO

FTE

NG

• Deltas can be recorded in a separate file and used to update files (e.g. for “patches”)

Version 1: Version 2:

eala

nd

Version 1:1 class X {2 // todo

id () {

Version 2:class X {

int m() {t 0Delta

klan

d | N

ew Z

e 3 void m() {4 }5 }

return 0;}

}

DeltaEncoding

vers

ity o

f Auc

k

Delta:Line 2: delete

The

Uni

v

7

Line 3: “int” for ”void”Line 4: insert “return 0;”

The Unified Diff Format/2012 • Standard format for

h i t h s Index: X.java===================

Filename

254

21/09/ exchanging patches

understood by most VCS• Example:

===================--- X.java (revision 6094)+++ X.java (working copy)@@ 1 5 +1 5 @@

SO

FTE

NG

• Example:remove comment andinsert “return;”

@@ -1,5 +1,5 @@class X {

– // todoid () {

Old and new version IDs

eala

nd

;

• Line-oriented:only full line insertions

void m() {+ return;

}List of text chunks:

-OldStart,#lines+NewStart #lines

klan

d | N

ew Z

e yand full line deletions

• No line parts or moving} +NewStart,#lines

+ for line add, - for line delete

vers

ity o

f Auc

k

• Some leading and trailing lines for each chunk for “fuzzy” patching (applying patch to version where it d t fit tl )

The

Uni

v does not fit exactly)8

Branches & Tags/2012

gBranches: different copies of a project which are developed

i lt l “ lf i t i d li f d l t”

254

21/09/ simultaneously; “self-maintained lines of development”

(/branches)– One main branch (/trunk)

SO

FTE

NG

– Maintenance branches: used for maintaining old versions which are still widely used (e.g. commercial OS)

– Experimental branches: used for trying out new features

eala

nd

Exper mental branches used for try ng out new features before merging them into the trunk

– Personal developer branches: for people trying out their own ideas

klan

d | N

ew Z

e own ideasTags: particular marked versions of the project (/tags)

– Can be used to refer to and recreate an old versionA t ll l lik f th j t t ti l i t

vers

ity o

f Auc

k – Actually also like a copy of the project at a particluar point in time

– Difference to branches: usually not changed any more

The

Uni

v

9

Version ControlBest Practices

/2012

Best Practices1. Complete one change at a time and commit it

254

21/09/ – If you committing several changes together you cannot

undo/redo them individually– If you don’t commit and your hard disk crashes

SO

FTE

NG

– If you don t commit and your hard disk crashes…– Continuous integration (see XP)

2. Only commit changes that preserve system integrity

eala

nd

y g p y g y– No “breaking changes” that make compilation or tests fail

3. Commit only source files (e.g. not .class files)

klan

d | N

ew Z

e

4. Write a log entry for each change– What has been changed and why

5 Communicate with the other developers

vers

ity o

f Auc

k 5. Communicate with the other developers– See who else is working on a part before changing it– Discuss and agree on a design

The

Uni

v

10

g g– Follow the project guidelines & specifications

/2012

254

21/09/

SO

FTE

NG

Managing Concurrency

eala

nd

Managing Concurrency

klan

d | N

ew Z

eve

rsity

of A

uck

The

Uni

v

11

Concurrent File Access:“Lost Update” Problem

/2012

Lost Update Problem• When sharing files developers

id t ll it 1 2

254

21/09/ can accidentally overwrite

each others changes• Consider two developers

ki h fil

1 2

SO

FTE

NG

working on the same file• Two approaches for solving

this:

eala

nd

– Reserved checkouts (“locking”)

– Unreserverd checkouts 3 4

klan

d | N

ew Z

e Unreserverd checkouts (“merging”)

• Many old version control systems support only locking

vers

ity o

f Auc

k systems support only locking (e.g. RCS, SCCS)

• Newer systems offer mergingB th h s h Images taken from

The

Uni

v

12

• Both approaches have disadvantages

Images taken fromthe SVN Book

(see resources page)

Locking(Reserved Checkouts)

/2012

(Reserved Checkouts)• Only one person can edit a 1 2

254

21/09/

y pfile at a time

• Before getting write access developer has to

1 2

SO

FTE

NG

access developer has to acquire the lock of the file

eala

nd

• Attempts to get lock while someone else has it failS ll h t it f H

3 4

klan

d | N

ew Z

e • Sally has to wait for Harry to release the lock

• Access to files is serialized

vers

ity o

f Auc

k Access to files is serialized• Workflow:

lock-modify-unlock

The

Uni

v

13

y

Merging (Unreserved Checkouts)

/2012

(Unreserved Checkouts)• Everybody can modify their working copy whenever they want

B h h b d i h h f h b f

254

21/09/ • But own changes have to be merged with changes of others before

they can be written to repository (copy-modify-merge)

SO

FTE

NG

1 2 3 4

eala

ndkl

and

| New

Ze

5 6 7 8

vers

ity o

f Auc

kTh

e U

niv

14

Merging Example/2012

g g pclass Test {

String m() {Developer A Developer B

254

21/09/ return "test";

} }

Developer Amakes achange

Developer Bmakes achange

SO

FTE

NG

class Test {String m(String t) {

class Test {String s = "test";

eala

nd

String m(String t) {return t;

} }

String m() {return s;

} }

klan

d | N

ew Z

e } }

l T t {

Merge

vers

ity o

f Auc

k class Test {String s = "test";String m(String t) {

fl

The

Uni

v

15Conflict: return s; or return t; ???

} }

Merging: Textual and Semantic Conflicts

/2012

Semantic Conflicts• Textual conflicts

Ch f diff t d l l l i

254

21/09/ – Changes of different developers are very close or overlapping

each other (“overlap”)– Merge tool cannot automatically combine them

M t l d t t h fli t & t th t th

SO

FTE

NG

– Merge tool detects such conflicts & reports them to the user– Version control system will refuse to write a file with

unresolved textual conflicts to the repositoryS ti fli t (l i l fli t )

eala

nd

• Semantic conflicts (logical conflicts)– Changes are semantically incompatible, but may not be

overlapping (e.g. in different files)E d l A h th d i t f th d

klan

d | N

ew Z

e – E.g. developer A changes method signature of method m, developer B inserts method calls to m using the old signature

– Non-overlapping semantic conflicts are not detected by a generic merge algorithm!!!

vers

ity o

f Auc

k generic merge algorithm!!!– Can be avoided by following specifications and communicating

with others• Both textual and semantic conflicts have to be resolved by the

The

Uni

v

16

• Both textual and semantic conflicts have to be resolved by the user

Locking vs. Merging/2012

g g gArguments against locking and for merging1 Administrative problems: people forget releasing

254

21/09/ 1. Administrative problems: people forget releasing

their locks; frequently administrators have to do it2. Unnecessary serialization: very counter-productive

SO

FTE

NG

y y p– Locking prevents people from editing different

parts of the same file– In reality conflicts occur rarely and can be

eala

nd

– In reality conflicts occur rarely and can be resolved without problems

– Conflicts usually indicate lack of communication

klan

d | N

ew Z

e

• Developers have not agreed on a proper design• With mutual agreement on design conflicts are

usually straightforward to merge

vers

ity o

f Auc

k usually straightforward to merge3. False sense of security: locking does not prevent

semantic conflicts of distributed changes (i.e. in different files)

The

Uni

v

17

different files)

Locking vs. Merging/2012

g g g

Arguments for locking and against merging

254

21/09/

g g g g g1. “Unmergeable” files: a generic merging tool does not

work for all file types

SO

FTE

NG

– For some formats (e.g. for Java class files) generic merging leads to many conflicts

eala

nd

– Conflicts can be very hard to resolve (e.g. for binary formats)

klan

d | N

ew Z

e

– One of two conflicting changes get lost (because they cannot be merged)

2 T diti i ti i ht h l d

vers

ity o

f Auc

k 2. Tradition: an organization might have always used a locking VCS

The

Uni

v

18

Today’s Summary/2012

y y

• A Version Control System manages the

254

21/09/

y m m gdifferent versions of all artefacts in a project– Many local working copies and one shared

SO

FTE

NG

Many local working copies and one shared repository

– Compressed with delta encoding

eala

nd

Compressed with delta encoding• Prevents lost updates through locking or merging

– Supports automatic merging and detects

klan

d | N

ew Z

e – Supports automatic merging and detects textual conflictsCannot detect non textual sematic conflicts

vers

ity o

f Auc

k – Cannot detect non-textual sematic conflicts– Conflicts always have to be resolved manually

The

Uni

v

19

Quiz/2012

Q

1. What is delta encoding? Give an example.

254

21/09/

g p

2. What is the difference between locking and

SO

FTE

NG

ff gmerging? When should each of it be used?

eala

nd

3. What is a semantic conflict? Why can it be a problem?

klan

d | N

ew Z

eve

rsity

of A

uck

The

Uni

v

20