CS5103 Software Engineering

1. CS5103 Software Engineering Lecture 11 Versioning 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 2

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 3

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 4

5. Basic Operations Fetch (Checkout, update) Commit 5

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; 6

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 7

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 8

9. Diff : A Real Example 9

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

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 11

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 12

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) 13

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! 14

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 15

16. Version Control Client: what should update/pull do? 16

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 17

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

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 19

20. Merge Conflict: change on the same line 20 20

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 21

22. Basic Update and Commit Rules Must update before commit Why? 22

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!! 23

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 24

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, … 25

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!! 26

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 27

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 28

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 Do not wait too long to merge 29

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 30

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 31

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 32

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 33

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 34

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 35

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 36

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 37

38. Version control: tips Write clear commit messages Better structured with some styles Example: 38

39. In the repository Most editions are small For efficiency: don’t 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 39

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) 40

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 41

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 42

43. Issue: an example 43

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 44

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 45

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 46

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 47

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 48

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 49

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 50