LECTURE 3:

Software Configuration Management

Ivan Marsic
Rutgers University 1
 Topics

 Definitions
 Working Scenarios
 Revision Control Functions
– Git and GitHub

2
Why Software Config Mgmt?
Software configuration management (SCM) is the process of
controlling the evolution of a software system
 Simplifies sharing code and other documents
 The ability to revert to an older version (“undo”)
 Coherently integrate contributions from team members
(“merge”)
 Notify interested parties about new modifications
(“reporting”)
 Track software issues (e.g., bugs)
 Create an auditing trail (“archiving”)
 SCM system allows us to answer questions:
– When was this software module last changed?
– Who made changes in this line of code?
– What is the difference between the current version and last week’s?
– How many lines of code did we change in this release?
– Which files are changed most frequently?
3
Why Software Config Mgmt?

 SCM simplifies collaboration and

increases productivity
 But it all can be done with
old-fashioned email, file system, etc.
– Naming convention?
– How to reconcile your version #1 with my version#1?

4
 Definitions
 A software configuration is a collection of work products
(“artifacts”) created during a project lifetime
 Software configuration item (SCI) is any piece of knowledge
(a.k.a. “work product” or “artifact”) created by a person
(developer or customer)
 A snapshot of a software configuration or a configuration item
represents the version of that item at a specific time
 A commit (or “check-in”) refers to submitting a software
configuration to the project database (“repository”)
 A build is a version of a program code (part of a software
configuration), and a process by which program code is
converted into a stand-alone form that can be run on a
computer (“executable code”)

5
 Repository vs. Workspace

Project database (“repository”)

Committed configurations
(at discrete times during project life)

retrieve commit
(or, pull (or, push
or, check-out) or check-in)
Private to individual developer

Working copies
(piecewise continuous development)
Developer’s workspace (“working directory”)

 Project database is usually on a remote server,

or “mirrored” on several servers
– This is the “team memory,” unlike individual workspaces that are private
 SCM provides a set of tools to interact with project
database 6
Version Graph and Branching
Time

Hotfix branch — to fix bugs in the mainline

Main branch (“trunk” or “mainline”) — in production (“fork”) (“merge”)

(“fork”)
root

Topic branch — new features development

 Each graph node (a “commit”) represents a “version”

of the software configuration shared with the team
– The private workspace of one team member was publicized in the shared
repository and becomes a part of “team memory”
 Think of branches as separate folders, each with its
own content and history
 The project snapshot at the tip of a branch
represents the latest version
7
 Example Working Scenarios
 Undoing mistakes in new work
 Supporting multi-pronged product evolution
– Parallel versions coexist at times, but will eventually merge (single
trunk—“Main”)
 Developing product lines
– Coexisting parallel versions (same product for different markets)
that will never merge (multiple trunks)
• but they still need synchronization so that versions for different markets are at the same
“level”

 Working with a small team of peers

– All developers can write to the project database
 Working with a managed team
– Only configuration manager can write to the project database

8
 Undoing Commits
Time “Tag” or identifier for a commit
main

C0 C1 C2 C3
root

main
Undo a commit:

C0 C1 C2 C3
root

 We can undo a commit; undo a merge;

or undo a checkout
 (See later how undo can be done
without deleting the history) 9
Multi-pronged Product Evolution
Hotfix branch

C4

Main branch

C0 C1 C5 C8

Develop branch

C2 C3 C7 C9

Topic branch

C6

 Parallel versions coexist at times, but will

eventually merge
(to a single trunk—Main branch) 10
 Working with Peers:
Centralized Workflow
() ()
Allow w rite Reject &
access to Accept request Accept
w hole team merge
Central
repository

Check-out Make change Check-in

Developer A

Check-out Make change Check-in Check-out Merge Check-in

Developer B
Time
() Assuming no other commits in the meantime; otherwise need to merge

 Example scenario: Two developers clone from the hub and both make changes
 The first developer to push his changes back up can do so with no problems
 The second developer must merge in the first one’s work before pushing
changes up, so as not to overwrite the first developer’s changes
11
 Working with a Managed Team
[change accepted] Merge w ith Push to [accepted]
Developer’s Project
Push to repository repository
Project
Configuration repository
Manager Notify or
request revise [rejected]
[change rejected] & resubmit

Project
repository

Developer
Push to Push to
Pull Pull
Pull Make change Developer’s Revise Developer’s
request request
repository repository
Developer’s
public
repository Time

 Example scenario:
 1. The configuration manager pushes the current version to the central project repository
 2. A contributor clones that repository and makes changes
 3. The contributor pushes the changed version to his own public repository
 4. The contributor notifies the configuration manager requesting to pull changes
 5. The configuration manager adds the contributor’s repository as a remote and merges locally
 6. The configuration manager pushes merged changes to the central project repository
12
 Git Commands Summary

clone
git clone <repo-URL>
commit
git commit -m "message"

pull
git pull origin <branch-name>

Shared repository
Developer’s on GitHub server
local repository
push
git pull -u origin <branch-name>
pull
push

Another team member’s

local repository

13
 Git: States of
Software Configuration Items
“untracked” file is in Tracked “tracked” file is in
developer’s working directory add the file (git add) developer’s local repository

Untracked Unmodified Modified Staged

edit stage
the file the file
remove
the file git commit

 git add is a multipurpose command (to begin

tracking new files, to stage files, etc.,
e.g., marking merge-conflicted files as resolved
 Using git add we signal to Git that we wish to
“add this content to the next commit”
(place it to the “staging area”)
 Next time we execute git commit,
Git will “add this file to the project” 14
Undo: Reverting vs. Resetting
Reverting: Resetting:
HEAD HEAD

C0 C1 C2 C0 C1 C2

C2 undone
Undo C2 commit: but not removed
Undo C2 commit:
HEAD HEAD C2 removed
from project history from
project history

C0 C1 C2 C1′ C0 C1 C2

 git revert undoes a committed snapshot C2 by undoing the

changes and appending a new commit C1′ (instead of removing
the commit C2 from the project history)  “safe”
– Historic record of abandoned versions exists

 git reset works backwards from the current commit by

removing all of the commits after the target commit  “unsafe”
– No historic record of abandoned versions
15
Merge on Large/Important Projects

(a) main develop (b) main develop

C0 C1 C2 C0 C1 C2 C5

C3 C4 C3 C4

topic topic

(c) main develop

C0 C1 C2 C5

C3 C4

 (a) Before a topic branch merge topic

 (b) After a topic branch merge

 (c) After a project release (“main” tag is moved) 16
 Rebasing Existing Branches

 Rebasing = moving a branch to a different

baseline commit
– Appears as if it forked off from a different version
– All commits in the branch are replayed on new base

MAIN MAIN

C1 C3 C4 C1 C3 C4 rebased
fork
fork
DEVELOP DEVELOP
git rebase
C2 C5 C2 C5 C2′ C5′

replayed commits
from the moved branch

17