1. CompSci 230 Software Construction
Lecture Slides #21: Version Control S1 2016

2. Agenda Topics: Development using version control
Why use version control?
Checking out, checking in, committing, merging
Tagging and branching
Good version control practice
CompSci 230: VC

3. Why version control As we develop software, we produce files, e.g.:
Documentation
Source code
Configuration / localization files
Images / graphics / icons
Build / deployment scripts
Tests
Tools
Data / database queries / scripts
Many of these files change over time and will be worked on by different people, in some cases at the same time?
CompSci 230: VC

4. Version control – basic problem
Alice and Bob work on the same development team
The team stores its current code base on a simple network drive
All developers can read from and write to this drive
A developer wanting to work on a file makes a copy of the file on his/her local machine, works on the copy, tests that the change works, and then copies the new version of the file back to the network drive
This way, the network drive always contains a “working” version of the code base.
At am, Alice copies the file CentralEngine.java to her disk for work.
At pm, Bob copies the file CentralEngine.java to his disk for work.
At pm, Alice copies the edited file CentralEngine.java back to the network drive.
At pm, Bob copies his edited version of the file CentralEngine.java back to the network drive, overwriting any changes that Alice made.
Alice is not happy!
CompSci 230: VC

5. Version control – non-technical solutions
Alice could have notified everyone that she was working on the file
Bob could have held off working on the file. What does this do to Bob’s productivity?
Is this reliable? What if Alice’s notification arrives after Bob checks for file availability? What if Alice forgets to tell people that she’s finished with the file?
Each file has an “owner” whose job it is to integrate any changes into the “official” version that is then stored on the network drive
Only owner has write access
Other developers send changes to the owner
How efficient is that?
CompSci 230: VC

6. Version control – other issues
What if we discover that a change that has been made has actually broken something?
When is a software code base stable?
How many changes / bug fixes / added features until the next stable version?
Can we fix bugs on one version while simultaneously refactoring the software for the next major version?
What about collaborative working with software that does not have all of its features yet?
E.g., a class where some methods are only implemented as stubs
CompSci 230: VC

7. Version control concepts
(Project) repositories, versions, branches, tags, commits, merges:
Repository contains project files for all versions and branches
Branches: versions of the repository for: different purposes, ongoing work
Trunk: main stable branch(es)
Checking out: download of a version of a document, typically for the purpose of editing
Commit: incorporation of edits into a branch
Merge: incorporating (committed) changes from another branch into a branch
Tags: like branches, but do not evolve further
Each commit generates a new version number
CompSci 230: VC

8. Version control repositories
Need to keep a copy of each file in every branch or tag every time the file is part of a commit or merge
Need to keep track which copy belongs to which branch / version
Is it a good idea to make a copy of the entire project file set every time we commit a change to a file (and hence create a new version)?
Issues:
Efficient storage
Speed of retrieval / branching
Locking during merges / checkouts
CompSci 230: VC

9. Trunks, branches and tags
Branches are essential development lines of the software
E.g., create a new branch to allow ongoing development work for a new release of the software while retaining the already released codebase branch for bug fixes
Create a new branch for a different software purpose (e.g., freeware version vs. commercial version)
Branches are creates as copies of existing versions of the software and evolve from there
Trunks are the main stable development lines (e.g., production code)
If we create a branch for development based on the production code, we will create it as a branch of the trunk
Tags are branches not intended for further development
CompSci 230: VC

10. Checkouts, updates, refreshing
Typically, repositories are kept on a server
When we check out a file, directory or whole project from a branch, we download a copy of the files
A good version control system keeps track of from which version we checked the files out
We then get to modify the files locally
The latest version in the branch in the repository may change while we do that. This is not reflected in the copies we work with unless we update our local copies by refreshing them from the repository.
Updates can create conflict if a file that we have edited locally has changed on the repository. These conflicts usually need to be resolved manually.
CompSci 230: UC

11. Commits and adds
When we have changed files in our local copy of a branch, we need to copy them back to the version control system. This is called a “commit”
Commits succeed if the file in the branch in the repository has not changed since we checked it out.
If the file has changed on the repository side, we need to resolve this conflict. E.g.: Rename the conflicted file locally, refresh from the repository, merge the content of the two files, and then attempt another commit.
If we want to add a new file, then this is usually a two-step process:
Add: register the file with the repository
Commit the file
A commit of a file generates a new version on the repository
CompSci 230: VC

12. Merging Merging is required when:
We attempt a commit, but the file has changed in the repository branch while we worked on it
We are trying to incorporate the changes from one branch into another branch
Merging can be performed automatically if:
The version control system is capable of automatic mergers, and
The version control system can deduct how to merge two versions of a file
E.g., one file has not changed, the other has had something added to it, or something was deleted
Automatic merging is not a trivial task
Manual merging of files that cannot be automatically merged may be assisted by the version control system, e.g., by adding markup to conflicted sections
What do you need to know in order to perform a manual merge, even if you can see the conflicted sections?
CompSci 230: VC

13. Example: Version control with GitHub
Github.com
Online repository with web interface, based on git version control
Need a (free) account to create your own repositories
Branches
master branch is where the production (or closest to deployable) code goes (think trunk)
To modify the code base, the developer generally creates a new branch (with a descriptive name, e.g., bobs-edits). This makes a copy of the master
Edit online (text format files only) or offline and/or upload files to branch
Developer commits changes to the branch first, then opens a pull request
Usually includes comments on what changed and why
Pull requests
A pull request opens discussion on changes / allows for review
Branch can continue to be modified when pull request is open and can be deployed in production if so desired or tested further
Merge
Merging code into master branch can be done semi-automatically
Conflicts can be flagged for manual resolution
Pull requests represent historical record – can track changes and why they were made
CompSci 230: VC

14. GitHub example
CompSci 230: VC

15. GitHub example
CompSci 230: VC

16. GitHub example
CompSci 230: VC

17. GitHub example
alices-edits is now a copy of the master branch – all files are still identical
CompSci 230: VC

18. GitHub example
bobs-edits is now also a copy of the master branch – all files are also still identical
CompSci 230: VC

19. GitHub example
(Bob – here impersonated by me) inspects HelloWorld.java in his branch…
CompSci 230: VC

20. GitHub example
…and edits HelloWorld.java by making a change in line 3 and adding a method.
CompSci 230: UC

21. GitHub example
Bob then commits HelloWorld.java to his branch, adding a comment to explain the what and why before he hits “Commit changes”…
CompSci 230: VC

22. GitHub example Pause for a moment… We now have:
The master branch, which still contains the original files, unchanged
The alices-edits branch, whose files are still identical copies of those in the master branch
The bobs-edits branch, which has a file that differs from the master branch
So let’s send Bob to lunch and give Alice a go…
CompSci 230: VC

23. GitHub example
Alice inspects the file – note it’s the original version, not the one that Bob edited. Alice then clicks on the pen symbol to edit the file...
CompSci 230: VC

24. GitHub example
Alice also makes a change to the same line and adds her own method, which she calls from main()
CompSci 230: VC

25. She then commits (with comment)
GitHub example
She then commits (with comment)
CompSci 230: VC

26. GitHub example
Note that Alice is told that GitHub can automatically merge her branch into the master branch.
Alice opens a pull request, which includes a comment
CompSci 230: VC

27. GitHub example The pull request gives others an opportunity to comment
Note: I’m impersonating Alice here
If there is no further discussion, we can merge the branches
CompSci 230: VC

28. Confirm the intent to merge
GitHub example
Confirm the intent to merge
CompSci 230: VC

29. GitHub example
The alices-edits branch has been merged successfully with the master branch – Alice can delete it if she wants: The two branches are identical again. Back to Bob, who is back from lunch and opens his own pull request…
CompSci 230: UC

30. GitHub example
Bob’s branch can’t be merged automatically with the master branch - GitHub detects this automatically
CompSci 230: VC

31. Github example
When we can’t merge a branch automatically in GitHub, we need to do so manually
Generally, this happens if the file has changed in both branches (e.g., master and bobs-edits here)
Git can’t work out what was intended so needs human input
A manual merge requires the command line version of git
GitHub website provides instructions
To start seeing what is going on, we can also open the branch in GitHub desktop
Note: GitHub desktop is not an editor, so can’t actually fix things here
Open command line version of git (e.g., via GitHub desktop), check out branch (e.g., bobs-edits) and open the conflicted file in an editor
CompSci 230: VC

32. Github example
In GitHub desktop:
CompSci 230: VC

33. Github example In GitHub desktop: Conflict area marker Divider
CompSci 230: VC

34. Github example
In Eclipse:
CompSci 230: UC

35. Github example In Eclipse, merged with conflict resolved:
CompSci 230: VC

36. Github example
Commit & push the commits to GitHub:
CompSci 230: UC

37. Github example
Can now open the pull request – and merge automatically:
CompSci 230: VC

38. Github notes This example showed me working on several branches
In reality, this would be several users, not just me!
Note how the conflict straddled method boundaries?
Merging files with lots of changes can be complex and challenging
What is better: Many small incremental pull requests and mergers or infrequent larger ones?
Merge conflicts can arise in other ways, too:
E.g., Alice has deleted a file & then merged her branch into master, while Bob has edited the same file.
When Bob tries to merge his branch into master later, what happens?
CompSci 230: VC

39. Other version control systems
The grandmother of all version control: RCS (Revision Control System), 1982
For individual files only, offers rudimentary branching
CVS (Concurrent Versions System), 1986/1990
Client-server architecture, works with file sets / projects, automatic merging
Apache Subversion, 2000
Git, 2005
Originally developed by Linus Torvalds for Linux development
CompSci 230: VC

40. Review Why use version control?
What is a repository, a trunk, a branch, a tag?
What are the two main purposes of creating a branch?
What happens when one checks out a file or file set?
What happens when one commits files?
What happens in a merge?
What is the difference between a commit and a merge?
What kind of changes allow for automatic merges?
What kind of changes don’t allow for automatic merges?
What is the purpose of a pull request?
CompSci 230: VC