cs5103 software engineering lecture 11 versioning and issue tracking

CS5103 Software

Engineering

Lecture 11Versioning and Issue

Tracking

2

Last class

Design patterns unfinished Visitor pattern

Singleton pattern

Basic Software Versioning Version

Server and client

Create version system for the course project

3

Today’s class

Version control system Diff

Merge

Branch

Distributed version control system

Issue tracking system Type of issues

Process of issues

Resolution of issues

4

Basic idea of Version Control A repository to store all staged versions

(actually a base version and differences for many version control systems)

A local copy for the user (or local copies for users) to edit

A user can fetch a staged version from the repository or commit a local copy as a new staged version to the repository

5

Basic Operations

Fetch (Checkout, update)

Commit

6

Diff A Diff is a description of the difference between

two versions of a document (source file)

The difference is described as how to change one version to make it become the other

The basic element of a diff is a lineVersion 1: Version 2:

x = 0; x = 1;

Y = 1; y = 1;

Diff:

- x = 0;

+ x = 1;

7

Diff Diff is a key operation of version control system

A lot of features of version control system and implemented based on diff

We use Diff(V1, V2) to denote the difference from v1 to v2 Note Diff(v1, v2) != Diff(v2, v1)

Diff(v1, v2) is the changes to made on v1 to make it v2

Diff(v2, v1) is the change to made on v2 to revert it to v1

8

Diff : Example

Diff(v1, v2) The change made for v2

svn diff –r 1:2

git diff 1..2

Diff(v2, LC) The local changes made since v2

svn diff –r 2

git diff 2

9

Diff : A Real Example

10

Diff : More complex

Diff can involve not only file edits New file

File deletion

Rename File

New directory

Directory Deletion

Change permissions

11

What to do with Diff

Read the diff Understand what is changed

Not a reason why diff is a key operation

Diff is not a very frequently used command for VC systems

Apply a diff Apply (Vx, Diff(Vy,Vz)), denotes applying the diff:

Diff(Vy, Vz) on Vx

12

Apply a diff: examples

Apply (LC, Diff(LC, v2)) Apply to LC the changes that will change LC to v2

So it is revert local copy to v2

Apply (LC, Diff(v2, v1)) Apply to LC the changes that will change v2 to v1

Revert the changes made for v2

Apply diffs is the base of several basic operations svn update, svn merge

git pull, git merge

13

Concurrent Development

Assume that we have 2 developers They use a repository on a server

They have their only local copies, LCA and LCB

When update, repository is changed to a new version (v13)

14

Version Control Client

Record the revision information of each file The repository version

The time of last checkout / pull

When update / commit, files can be Unchanged, current – no change in LC and Repo

Changed, current – only changes in LC Commit will apply changes to repository

Unchanged, outdated – only changes in Repo Update will apply change to LC

Changed, outdated – both LC and Repo changes Need to merge!

15

Concept: parents

A parent of a revision is the version that the revision is made on

A revision has 0 – 2 parents

Initial commit : 0 parent

Normal edit : 1 parent

Merge : 2 parents

Transition of parents -> ancestors

16

Version Control Client: what should update/pull do?

V12:

20: void f (int i){21: int j = 2;22: print(i+j);23: }

LC:


After update:

20: void g (int i){21: int j = 3;22: print(i+j);23: }

V13:


17

During the update/pull

Find common ancestor (v12)

Compute Diff(v12, v13): replace line 20 with

“void g(int i)”

Apply Diff(v12, v13) to LC

LC:


After update:


18

Another process

Find common ancestor (v12)

Compute Diff(v12, LC): replace line 21 with

“int j = 3”

Apply Diff(v12, LC) to v13

V13:


After update:


19

Well-defined merge

A merge is well defined If all different process get the same results

Apply(LC, Diff(v12, v13)) == Apply (v13, Diff(v12, LC))

Or geneneral:

Ancestor + change1 + change 2 = Ancestor + change2 + change1

20

Merge Conflict: change on the same line

20

V12:


LC:


After update:

20: void g (int i){21: int j = ??;22: print(i+j);23: }

V13:


21

Merge Conflict Happens

Merge will leave a partially merged file

Your change and repo change will both appear in the file

Edit the file and commit the manually merged file

22

Basic Update and Commit Rules

Must update before commit Why?

23

Merge is textual

Code may not work after merge Developer A makes the change:

f (int x, int y) -> f(int x, int y, int z)

Developer B makes the change: insert f(a, b)

No merge problems Code will not compile

It is lucky that it does not compile!

Communication: notify the people who may be affected

Auto test suite and Regression testing!!

24

Branch

The repository has a linear history currently

v13 is released as product v1.0

Users report bugs on v13: need to fix

Developers already headed to v2.0 (e.g., may change the whole GUI style or data format)

We need a branch to hold the fixes

25

Other reasons for branches?

Temporary versions Implement new features (tentative)

Isolate changes to have a stable trunk

Eventually merge back to the trunk

Snapshot for testing Development continues

Fixes eventually merge back to the trunk

Separate branch for different release Lighter version

Different OS, …

26

What’s new with branches

Similar to collaborative development Parallel histories

Merge changes

You have multiple histories in repository The most difficult thing is still merging

Checkout both branches merge locally and resolve conflicts recommit

So do not afraid of branches!!

27

Merge Branches

Merge changes of a branch to the trunk Done on a local copy

Find the common ancestor(v12)

Find changes fro v12 to v16branch

Apply changes to v15trunk

28

Merge Branches: tracking

Branch may continue after a merge

Goes to v18 and v20

Branch records the last merge (v16)

Apply Diff(v16branch, v20branch) to v19trunk

29

Branching strategies: stable trunk

Trunk for stable release

Branches for adding tentative features

Advantages: Trunk is always stable

Small teams can work independently

Disadvantage: May cause huge merging efforts

30

Branching strategies: branch release

Trunk for development

Branches for stable releases

Advantages: More intense communication:

Smaller merges: less mistakes and efforts

Actually better utilizing version control systems

Disadvantage: Sometimes, no stable version is available

31

Branching strategies: parallel trunk

Trunk for stable versions

Developing branch for development

Trunk and develop are parallel

Non-admin developers only work on develop (it is actually their trunk)

Administrator merge develop to trunk when the develop is stable

32

Multiple repositories

So far: a repository shared by the whole team

Disadvantages: Everybody need to write to the repository

Not nice to submit partial work

Developer cannot use version control locally

Hacking solutions: hard to manage Have a local repo, and submit in stages

Develop trunk to restrict write access

33


Basic idea Everybody has and uses his/her own repository

The code in a local repository is like a branch (but stored locally)

Remote updates and commits are just like branch merges

There can be a central repository or not Usually there is one for easier management

Owner of central repository has the write access Fetch other people’s branch for merge

34

DVCS: example

Alice (admin)

Start repo with A1 and A2

A3 is a branch

Bob joins, and pull

Alice’s trunk

A3 is private for Alice

Bob fixes a bug Got B1

Alice finish A3

Got A4

35

DVCS: example

Chris joins and pulls

Alice’s trunk (A4)

Chris got C1 and C2

Alice move to A5

Chris want a merge

Alice pull C1 from Chris

Alice get A6

Bob knows A6 and pull it

Bob merge to get B2

36

DVCS: summary

A central repository usually exist (Alice)

Everybody only write their own repo, and read from others However, usually, Alice is writable for easier

communication

Everybody (Alice, Bob, and Chris) uses their own repo for local development

37

Version control: tips

Small commits Place every logically separate change as a commit

Allows more meaningful commit messages

Reverted independently

Avoid commit noises Make sure the code build before commit (especially

after merge)

Unit test or if possible an automatic test suite

38

Version control: tips

Write clear commit messages

Better structured with some styles

Example:

39

In the repository

Most editions are small

For storage efficiency: do not store entire new file Store changes from previous versions

Make commit / update slower Apply diffs when there is no merge

Binary files Use entire file

Branch is quite cheap No changes to files are made at the branch time

More revision records when changes come later

40

Issue Tracking System

As we mentioned Version control system requires communication to

work well

Developers need to share their ideas on development tasks

Mailing list Hard to manage, come with all other mails

Not categorized by topic

No features for describing specific aspects in SE (versions, components, commits, etc)

41


A platform for developers to communicate with each other

Like a forum

People can register and raise a issue

The one who raise the issue will describe the issue in details

Others can comment

42


What is special

More structured for describing issues Component, assignees, schedules, status, resolution

Customizable

Change the contents while progress is made (status, resolution)

Sometimes allow anonymous issue raising Users of software are involved

They use the software and raise bugs

43

Issue: an example

44

Type of Issues

Bug report (e.g., system shows wrong message) About a bug of the software Raised by a user/developer Should include:

Step to reproduce Expected behavior Actual behavior Stack trace or error message if any

New feature (e.g., add sorting to results) About add a new feature, e.g., add sorting by modify

time Raised by a user/developer

45

Type of Issues

Patch (e.g., add checking for input validity) A fix to the software By a professional user or a developer on a important fix Should include:

Version to patch Patch code: basically a code diff, Diff (buggy, correct)

Milestone (e.g., move to json data format) A milestone is a short-term target for software dev A list of features or fixing a number of bugs, or both By the team leader Communication about the progress toward the

milestone

46

Process of an issue

Open/New The issue is raised

Nobody in the project has looked at it yet

Assigned A person called triager assign issue to a developer

Bug report: the developer will first reproduce the bug, and then try to fix

Feature request: discuss with colleagues on whether to accommodate the request, and implement the feature

Patch: Validate the patch

Milestone: may be assigned to a sub-group

47

Process of an issue

Closed When the decision on the issue is made in any way

Fixed, usually accompany with code commits Reject Later

Reopened After the issues is closed, something happens and the

issue become active again Incomplete fix

Start to implement a postponed feature Or revoke any wrong decision before

48

Resolution of an issue

Fixed A bug is fixed

A feature is added

A patch is applied

Invalid Bug cannot be reproduce

Feature does not make sense (request is not understandable)

Patch is not correct

49

Resolution of an issue

Duplicate The issue is a duplicate of another existing issue

Often happens for user raised issues

Usually bug report / feature request

Some issue tracking system allows merge of duplicate issues

Won’t fix The developers decide to not fix the bug or

accommodate the new feature

Limited human resource, new version is about to released

50

Issue Tracking Systems Many project hosting websites provide issue

tracking systems also Google Code: so you will also have a issue tracking

system

GIT Hub

Source Forge

Issue tracking service provider: Bugzilla

Companies often has their own issue tracking system Users can submit issues, but the tracking system is

not public

51

Tips on submitting an issue report Search for existing reports

Specify: product, platform/OS, version

Describe

Input / Steps to reproduce

Expected results / actual results

Bug: Always reproducible or happen randomly (maybe related to concurrency, system resource, environ, etc.)

Provide

Snapshot / bug: error message

Bug: Stack trace

52

Tips on triaging and handling issue reports Triaging:

Search for existing reports

Talk with the developers who are familiar with the area

Decide the severity and who should handle the report (according to the expertise and workload)

Handling an issues report (e.g., fix, add feature) Reproduce

For features: communicate on the issue tracking system about whether and how to support it

If reproducible Always report progress as comments in the issue

tracking system: others may help or change their work accordingly

53

Today’s class

Version control system Diff

Merge

Branch


Issue tracking system Type of issues

Process of issues

Resolution of issues

54

Next class

Coding styles Variable Naming

Interface Definition

Comments

Code Formatting

Tools

API comments and Documentation Comments of public methods

JavaDoc

55

Thanks!

cs5103 software engineering lecture 11 versioning and issue tracking

Documents