Software Engineering Tools and

Practices

Chapter 6
Revision Control

friesbaht 1
Chapter Outline
 Introduction to revision Control
 Version Control Configuration and Use
 Cloning an existing repository

friesbaht
Introduction

 What is Revision control?

 In software development process,  revision
control, also known as version control or source
control, is the management of changes made over
time.
 These changes can be to source code, project assets,
or any other information that goes into the finished
product.

friesbaht
Cont.…
 It permits many people to work on the same parts of a
project without worrying that their changes will 
overwrite the work of anyone else.
 The collection of revisions and their metadata is
called a repository or repo.
 The repository represents a step-by-step
chronological record of every change made to help
project managers revert all or part of the project to a
previous state if necessary.

friesbaht
How revisions are made?
 Revision control systems are usually hosted on
a networked server.
 After the repository is set up, it involves the
following steps:

S-1:- If the developer has created a new file that

should become part of the project, the file must
be added to the repository.

friesbaht
Cont.….
 S-2:- If the developer wants to edit a file that is
already part of the project, the file must be checked
out (is known as the "head").

 S-3:- After the developer edits the file locally and is

ready to add it to the official version of the project,
the file can be checked in.
 This action is also known as making a commit.

friesbaht
Cont…
 S-4:- If someone else has checked in revisions to the same
file since the last time the developer checked it out, the
system announces that there are conflicts.
 It calculates the differences line-by-line, and the
developers who made the changes must agree upon how
their individual changes should be merged.

 S-5:- If there are no conflicts, the new version is updated

in the repository, and the entire project receives a
new revision number, permanently and uniquely
identifying its current state.
friesbaht
Branching the development tree
 Experimental changes are often made to the main
version of a software project.

 Using revision control, these changes can be made to

a separate copy of the project without interfering with
development of the main version.

 The terminology for this approach uses the metaphor

of a tree: the main version of the project is called
the trunk, and experimental versions are known
as branches
friesbaht
List of revision control software
 Aegis: Used for TDD (test-driven development).
 Azure DevOps Server: developed by Microsoft,
providing source code management and collaborative
tools for software development.
 Git: A distributed revision control system designed
and implemented by Linus Torvalds for use in the
development of the Linux kernel.
 Git is now the most widely-used version control
system in the world and it is free, and open source.

friesbaht
The stages of developing a software application:
 Requirements Analysis
 High-level Design
 Low-level Design
 Implementation
 Integration
 Deploy (SDL)
 Maintain (SDL)

friesbaht
In many cases, multiple projects
run concurrently

New features are typically

being added to the next
version

While at the same time,

defects need to be
corrected in existing
releases

You will do this more in SDL

friesbaht
SE 4091
Dileep Kumar G.
On a single project, a team of software
engineers work together toward a release

All team members work on the

same code and develop their
respective parts

An engineer may be
responsible for an entire class

Or just a few methods within a

particular class
friesbaht
 Files have to be shared among developers on a
team project

Shared files can be kept in

some type of Repository
where they can be
accessed and worked on by
multiple individuals

Harry and Sally get their own respective local Working Copies of the
Master File in the Repository

Image: http://svnbook.red-bean.com/ friesbaht

 What might you use for a Repository?
Would any of these work?

 USB/SD drive

 Private network drive

 E.g. shared “X:” drive

 Cloud drive
 Google drive
 Dropbox
 iCloud

Image: http://svnbook.red-bean.com/ friesbaht

 Sharing files can lead to big problems…

Adds some method Modifies some other method

Image: http://svnbook.red-bean.com/ friesbaht

 The problem to avoid:

Harry’s changes are still held locally…

Image: http://svnbook.red-bean.com/ friesbaht

 Harry’s changes are lost

‘’

Harry’s local file gets overwritten with

Sally’s latest changes.

‘’

Image: http://svnbook.red-bean.com/ friesbaht

The Issue: Effective management of software
artifacts, especially code
Some acronyms:
 SCM – Source Code Management
 SCCM – Source Code Configuration
Management
 RCS – Revision Control System
 VCS – Version Control System
 DVCS - Distributed Version Control Systems

friesbaht
 Revision/Version History might help
 …but USB/SD, private network drives do not
maintain revision history

 Cloud drives (e.g. Google Drive, Dropbox,

iCould/Time Machine) maintain a (limited)
history of the various revisions of a file
 Google Drive: keeps last 100 revisions or last 30
days
 Supported in “Classic” mode only – going
away?

 IF you detect a collision, you can manually

merge the differences and resynchronize your
work
 Might be workable for two people – what about 5
or 10?
friesbaht
Any other disadvantages to Google
Drive/Dropbox/iCloud
 Security?
 Support (bug fixes and new features)?
 Ownership of stored information?
 Cost?
 Ease of Use?
 Acceptance?

friesbaht
Special-purpose Revision Control
Systems have been around a lot
longer than Google Drive or Dropbox
 SCCS, 1972 (IBM)
 RCS, 1982 (Unix)
 SourceSafe 1995 (Microsoft)
 CVS, 1986 (multi-platform)
 SVN, 2000 (multi-platform)
 Git and Mercurial, 2005 (multi-platform)

The way these work has evolved over the

years
friesbaht
Features of version control systems
 All changes to a file are tracked
 Version histories show who, what, when

 Changes can be reverted (rewound to any

earlier version)

 Changes between revisions are easy to

identify

friesbaht
 The Lock-Modify-Unlock solution

Sally must wait until Harry releases the lock,

although she can retrieve a “readonly”
version of the file in the meantime.
Image: http://svnbook.red-bean.com/ friesbaht
 Lock-Modify-Unlock only allows a
single user to edit the file at a time

Sally must continually poll the system to

see if the file has been unlocked, or Harry
needs to tell her when he unlocks it.

Image: http://svnbook.red-bean.com/ friesbaht

Lock-Modify-Unlock has certain drawbacks:

Harry has to remember to release his lock

before Sally (or anyone else) can acquire the
lock in order to edit

Sally has to wait for Harry to finish before

editing (editing must be done sequentially)
 Harry might be adding some new methods (takes
a long time)
 Harry might forget to release the lock before
going home (or on vacation!)
friesbaht
The Copy-Modify-Merge solution allows concurrent
editing

CVS, SVN use this model

Harry adds Sally adds

new methods comments

Image: http://svnbook.red-bean.com/ friesbaht

 The Repository recognizes conflicts

Harry is prevented from writing

Image: http://svnbook.red-bean.com/ friesbaht

 Conflicting versions of the files are merged

Conflicts are automatically

resolved in many cases using
robust merging algorithms.

However, manual merging is

sometimes necessary and can
introduce errors.

Image: http://svnbook.red-bean.com/ friesbaht

 The Repository keeps both users synchronized

Image: http://svnbook.red-bean.com/ friesbaht

Copy-Modify-Merge is generally easy to use and manage

Users can work in parallel

Most of the time, concurrent changes

don’t overlap
 People generally don’t edit exactly the
same code simultaneously, so merging is
done automatically in many cases
 Amount of time spent resolving conflicts is
nearly always less than the time that would
be spent waiting for a lock to be released
friesbaht
Is Lock-Modify-Unlock ever needed anymore?

When two or more people need to

work on the same file, the
simultaneous changes may not
be mergable in all cases:
 MS Office documents
 Image documents
 Other binary files

friesbaht
Subversion is an open-source version
control system that is available and still
supported for many platforms
 Windows
 Mac
 Linux

Many current open-source projects use

Subversion to maintain source code control
 http://subversion.tigris.org/
 Latest release 8/2021

friesbaht
 Subversion’s main drawback is the
centralized nature of the Repository

A repository is typically hosted

on a server.

 Version history is on the

server, not on your local PC
 If the server or network
become unavailable,
everyone gets stuck with the
working copy they have.

Image: http://svnbook.red-bean.com/ friesbaht

 Distributed Version Control
A “remote master” repository is
typically hosted on a server.
 Clones of the remote repository are
maintained on each user’s
computer
 If the server goes down, users can
continue sharing code (provided
they can connect over a network)
by synch’ing to each others’
repositories
 If the network is unavailable, users
can continue reading & writing to
their own local repository –
synch’ing with others later Git and Mercurial use this
friesbaht model
Image: http://git-scm.com/book/
Merging in a DVCS, part 1

1. Initially, both users’ repositories

2. Both users edit the same file, and their
are synch’d to the remote master;
local repositories reflect their changes
All files are identical.
friesbaht
Merging in a DVCS, part 2

4. User B attempts to “push” his repository

3. User A “pushes” her repository to the remote to synch; this fails due to
to the remote master to synch; this User A’s earlier push. Remote does
friesbaht
succeeds. not change.
Merging in a DVCS, part 3

5. User B “pulls” User A’s 6. User B “pushes” his repository

updates from the remote master, to the remote to synch; this now succeeds
merging A and B together.
friesbaht
Merging is automatic with some
exceptions.
Merging in a DVCS, part 4

7. User B “pulls” from the remote, and everyone is in synch again.

friesbaht
Repositories can also manage and track differences
between parallel revisions of a document

 Typically, a software product will undergo

parallel development on different branches (e.g.
for new/future features) while primary
development takes place on the main (master)
branch

Image: http://svnbook.red-bean.com/ friesbaht

Git takes snapshots

friesbaht
Git uses checksums
 Git generates a unique SHA-1 hash – 40
character string of hex digits, for every
commit.
 Often we only see the first 7 characters:
1677b2d Edited first line of readme
258efa7 Added line to readme
0e52da7 Initial commit

friesbaht
 A Local Git project has three areas

Unmodified/modified Staged Committed

Files Files Files
Note: working directory sometimes called the “working tree”, staging area sometimes called the “index”.
friesbaht
Git file lifecycle

friesbaht
Basic Workflow
Basic Git workflow:
1. Modify files in your working directory.

2. Stage files, adding snapshots of them to your

staging area.
3. Do a commit, which takes the files as they are
in the staging area and stores that snapshot
permanently to your Git directory.
 Notes:
 If a particular version of a file is in the git directory, it’s considered
committed.
 If it’s modified but has been added to the staging area, it is staged.
 If it was changed since it was checked out but has not been staged, it is
modified. friesbaht
Aside: So what is github?
 GitHub.com is a site for online storage of Git repositories.
 
 Many open source projects use it, such as the Linux kernel
. 
 You can get free space for open source projects or you can
pay for private projects.

Question: Do I have to use github to use Git?

Answer: No!
 you can use Git completely locally for your own purposes, or
 you or someone else could set up a server to share files, or
 you could share a repo with users on the same file system, (as long everyone
has the needed file permissions). friesbaht
Get ready to use Git!
1. Set the name and email for Git to use when you commit:
$ git config --global user.name “Bugs Bunny”
$ git config --global user.email bugs@gmail.com

 You can call git config --list to verify these are set.
 These will be set globally for all Git projects you work
with.
 You can also set variables on a project-only basis by not
using the
--global flag.
 You can also set the editor that is used for writing commit
messages:
$ git config --global core.editor emacs (it is vim by
friesbaht
default)
Create a local copy of a repo
2. Two common scenarios: (only do one of these)
a) To clone an already existing repo to your current directory:
$ git clone <url> [local-dir-name]
This will create a directory named local-dir-name, containing a
working copy of the files from the repo, and a .git directory
(used to hold the staging area and your actual repo)
b) To create a Git repo in your current directory:
$ git init
This will create a .git directory in your current directory.
Then you can commit files in that directory into the repo:
$ git add file1.java
$ git commit –m “initial project version”

friesbaht
Git commands
command description
git clone url [dir] copy a git repository so you can add to it
git add files adds file contents to the staging area
git commit records a snapshot of the staging area
git status view the status of your files in the working
directory and staging area
git diff shows diff of what is staged and what is
modified but unstaged
git help [command] get help info about a particular command
git pull fetch from a remote repo and try to merge
into the current branch
git push push your new branches and data to a
remote repository
others: init, reset, branch, checkout, merge, log, tag

friesbaht
Init a repository
zachary@zachary-desktop:~/code/gitdemo$ git init
Initialized empty Git repository in /home/zachary/code/gitdemo/.git/

zachary@zachary-desktop:~/code/gitdemo$ ls -l .git/
total 32
drwxr-xr-x 2 zachary zachary 4096 2011-08-28 14:51 branches
-rw-r--r-- 1 zachary zachary 92 2011-08-28 14:51 config
-rw-r--r-- 1 zachary zachary 73 2011-08-28 14:51 description
-rw-r--r-- 1 zachary zachary 23 2011-08-28 14:51 HEAD
drwxr-xr-x 2 zachary zachary 4096 2011-08-28 14:51 hooks
drwxr-xr-x 2 zachary zachary 4096 2011-08-28 14:51 info
drwxr-xr-x 4 zachary zachary 4096 2011-08-28 14:51 objects
drwxr-xr-x 4 zachary zachary 4096 2011-08-28 14:51 refs

friesbaht
Stage the Changes
zachary@zachary-desktop:~/code/gitdemo$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# modified: hello.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

friesbaht
Review Changes
zachary@zachary-desktop:~/code/gitdemo$ git add hello.txt
zachary@zachary-desktop:~/code/gitdemo$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: hello.txt
#

friesbaht
 Committing files
 The first time we ask a file to be tracked, and every time
before we commit a file we must add it to the staging area:
$ git add README.txt hello.java
This takes a snapshot of these files at this point in time and adds
it to the staging area.
 To move staged changes into the repo we commit:
$ git commit –m “Fixing bug #22”

Note: To unstage a change on a file before you have committed it:

$ git reset HEAD - filename
Note: To unmodify a modified file:
$ git checkout - filename
Note: These commands are just acting on yourfriesbaht
local version of repo.
Status and Diff
 To view the status of your files in the working directory
and staging area:
$ git status or
$ git status –s
(-s shows a short one line version similar to svn)

 To see what is modified but unstaged:

$ git diff

 To see staged changes:

$ git diff -cached

friesbaht
Viewing logs
To see a log of all changes in your local repo:
 $ git log or

 $ git log -oneline (to show a shorter version)

1677b2d Edited first line of readme
258efa7 Added line to readme
0e52da7 Initial commit
 git log -5 (to show only the 5 most recent updates, etc.)

Note: changes will be listed by commitID #, (SHA-1 hash)

Note: changes made to the remote repo before the last time you
cloned/pulled from it will also be included here

friesbaht
Pulling and Pushing
Good practice:
1. Add and Commit your changes to your local repo
2. Pull from remote repo to get most recent changes (fix conflicts if
necessary, add and commit them to your local repo)
3. Push your changes to the remote repo
To fetch the most recent updates from the remote repo into your local repo,
and put them into your working directory:
$ git pull origin master
To push your changes from your local repo to the remote repo:
$ git push origin master
Notes: origin = an alias for the URL you cloned from
master = the remote branch you are pulling from/pushing to,
(the local branch you are pulling to/pushing from is your current branch)
Note: On attu you will get a Gtk-warning, you can ignore this.

friesbaht
Branching
 To create a branch called experimental:
$ git branch experimental
 To list all branches: (* shows which one you are currently on)
$ git branch
 To switch to the experimental branch:
$ git checkout experimental
 Later on, changes between the two branches differ, to
merge changes from experimental into the master:
$ git checkout master
$ git merge experimental

Note: git log --graph can be useful for showing branches.

Note: These branches are in your local repo!
friesbaht
Do This:
1. $ git config --global user.name “Your Name”
2. $ git config --global user.email youremail@whatever.com

3. $ git clone https://github.com/rea2000/fresbhat.git

Then try:
4. $ git log, $ git log --oneline
5. Create a file named userID.txt (e.g. rea.txt)

6. $ git status, $ git status –s

7. Add the file: $ git add userID.txt
8. $ git status, $ git status –s

9. Commit the file to your local repo:

$ git commit –m “added rea.txt file”
10.$ git status, $ git status –s, $ git log --oneline
*WAIT, DO NOT GO ON TO THE NEXT STEPS UNTIL YOU ARE TOLD TO!!
11.Pull from remote repo: $git pull origin master
12.Push to remote repo: $git push origin master
friesbaht
Git Resources
 At the command line: (where verb = config, add, commit,
etc.)
$ git help <verb>
$ git <verb> --help
$ man git-<verb>
 Free on-line book:  http://git-scm.com/book
 Git tutorial: http://schacon.github.com/git/gittutorial.html
 Reference page for Git: http://gitref.org/index.html
 Git website: http://git-scm.com/
 Git for Computer Scientists (http://eagain.net/articles/git-
for-computer-scientists/)

friesbaht
Self-Review Questions
1.List out tools that exist for version control?
2.What are the features of distributed version
control?
3.List out Git commands?
4.Write code snippet for creating a jar file?
5.Write code snippet to demonstrate the concept
of unit testing using JUnit?

friesbaht