1. CS5103 Software Engineering Lecture 11 Versioning and Issue Tracking

2. 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. 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. 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. 5 Basic Operations  Fetch (Checkout, update)  Commit

6. 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 line Version 1: Version 2: x = 0; x = 1; Y = 1; y = 1; Diff: - x = 0; + x = 1;

7. 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. 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. 9 Diff : A Real Example

10. 10 Diff : More complex  Diff can involve not only file edits  New file  File deletion  Rename File  New directory  Directory Deletion  Change permissions

11. 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. 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. 13 Concurrent Development  Assume that we have 2 developers  They use a repository on a server  They have their only local copies, LC A and LC B  When update, repository is changed to a new version (v13)

14. 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. 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. 16 Version Control Client: what should update/pull do?

17. 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

18. 18 Another process  Find common ancestor (v12)  Compute Diff(v12, LC): replace line 21 with “int j = 3”  Apply Diff(v12, LC) to v13

19. 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. 20 Merge Conflict: change on the same line 20

21. 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. 22 Basic Update and Commit Rules  Must update before commit  Why?

23. 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. 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. 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. 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. 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 v16 branch  Apply changes to v15 trunk

28. 28 Merge Branches: tracking  Branch may continue after a merge  Goes to v18 and v20  Branch records the last merge (v16)  Apply Diff(v16 branch, v20 branch ) to v19 trunk

29. 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. 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. 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. 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. 33 Distributed version control system  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. 34 DVCS: example  Alice (admin)  Start repo with A 1 and A 2  A 3 is a branch  Bob joins, and pull Alice’s trunk  A 3 is private for Alice  Bob fixes a bug  Got B 1  Alice finish A 3  Got A 4

35. 35 DVCS: example  Chris joins and pulls Alice’s trunk (A 4 )  Chris got C 1 and C 2  Alice move to A 5  Chris want a merge  Alice pull C 1 from Chris  Alice get A 6  Bob knows A 6 and pull it  Bob merge to get B 2

36. 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. 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. 38 Version control: tips  Write clear commit messages  Better structured with some styles  Example:

39. 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. 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. 41 Issue Tracking System  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. 42 Issue Tracking System  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. 43 Issue: an example

44. 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. 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. 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. 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. 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. 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. 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. 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. 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. 53 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

54. 54 Next class  Coding styles  Variable Naming  Interface Definition  Comments  Code Formatting  Tools  API comments and Documentation  Comments of public methods  JavaDoc

55. 55 Thanks!