Title: Configuration Management
1Configuration Management
Seminar in Software Design - 2005/6
- Aviva Dayan
- Arik Gendelman
- Pablo Galiana
2What is Configuration Management?
- The control of changes made throughout the system
lifecycle. - Allows changes to be evaluated before they are
approved. - Considers interrelationships among system
components.
3Software Configuration Management
- A software engineering discipline
- Comprised of tools and techniques
- used to manage change to software assets.
- A set of activities to control change by
- identifying the products establishing
relationships - defining mechanisms for management, control,
auditing and reporting on changes made. - In short A methodology to control and manage a
software development project.
4Why do we need SCM?
- To manage
- Many people working on the same code.
- Projects delivered in several releases (builds).
- Rapid evolution of software and hardware.
- Project surveillance
- i.e. projects status, bugs, features, etc.
- Concurrent support and development.
- Stress time requirements of projects.
5Goals of SCM
- Configuration Control
- Controlling product release and its updates.
- Status Accounting
- Recording and reporting components status.
- Review
- Ensuring completeness and consistency of all
parts. - Build Management
- Managing the build process and its tools.
6Goals of SCM cont.
- Process Management
- Ensuring adherence to the development process.
- Environment Management
- Managing the components that host our system.
- Teamwork
- Facilitate team interactions
7SCM How it is accomplished?
- All these goals are accomplished through
- Version control
- Management of multiple revisions of the same unit
of information.
8Version control
- Commonly used in engineering and software
development. - Changes identified by incrementing an associated
number or letter code - revision number, or
revision level. - Revision numbers (levels) are associated
historically with the person making the change.
9Vocabulary
- Repository
- A server where the files are stored.
- Check-Out
- copies a working copy from the repository
- (the opposite of an import).
- Change
- A specific modification to a document under
version control. - The granularity of the modification considered a
change varies between version control systems.
10Vocabulary cont.
- Change List
- The set of changes made in a single commit.
- A sequential view of the source code.
- Commit or Check-in
- Copy the changes on the local files to the
directory. - (the VC software takes care of changes since the
last synchronization). - Update
- copies the changes that were made to the
repository into your working directory. - (opposite of a commit).
11Vocabulary cont.
- Merge / Integration
- brings together (merges) concurrent changes into
a unified revision. - Revision or version
- one version in a chain of changes.
- Conflict
- Occurs when two changes are made by different
parties to the same document or place within a
document. - Resolve
- The act of user intervention to address a
conflict between different changes to the same
document.
12Example
CM Clients
CM Server
Trunk
Machine A
Machine B
13History
- CM systems save the files history.
- Old versions can be viewed, compared, and
downloaded. - New versions can be (irreversibly) replaced with
old versions and wiped off the map.
14Central repositories
- Files are saved in a central file server.
- Developers can view the files in the repository,
through the use of filters.
15Labels
- Several files can be labeled together.
- Allows
- Access to the label as a whole set of files.
- Changes to the labeled files as a unit.
- Useful for marking product releases.
16 Check-in
- Copies a file into the database.
- The version you see is (usually) the latest
version that was checked in. - The old version is kept and can be accessed later.
17Check out
- Copies the database file to your personal folder,
and raises a flag on the database copy. - Need to check out before checking in.
18Undo check out (uncheck-out)
- The undo checkout command does just that the
file returns to the status it had before it was
checked out. - This can be done even if changes have been made
to the local copy of course, these do not go
into the database!
19Versioning Models
- Lock-Modify-Unlock Solution
- Only one person can change a file at a time.
- Example VSS.
- Copy-Modify-Merge Solution
- Users modify private copies only - in parallel
- Private copies are merged together into a new,
final version. - Example CVS, Subversion.
20Problems With Locking
- Administrative problems
- A user can lock a file and forget about it.
- Time is wasted while others wait to edit the
file. - Unnecessary serialization
- Different parts of a file dont necessarily
overlap. - E.g. Alice works on the beginning of a file, Bob
wants to edit the end of the same file.
21Problems With Locking cont.
- False sense of security
- Lets say Alice locks and edits file A, while Bob
simultaneously locks and edits file B. - Lets say A and B depend on one another, and the
changes made to each are semantically
incompatible. - Suddenly, A and B don't work together anymore.
22The Copy-Modify-Merge Solution
Repository
Aviva and Arik both check out file A. Here,
checkout has no locking effect its just a
local copy.
Read
Read
23The Copy-Modify-Merge Solution
Both edit their local files.
Repository
24The Copy-Modify-Merge Solution
Repository
Aviva checks in her file to the repository first.
Write
25The Copy-Modify-Merge Solution
Repository
Now, Arik tries to check-in his file. He gets an
up-to-date check error
Write
26The Copy-Modify-Merge Solution
Arik updates his local copy to contain the
changes made by Aviva. Changes are added to the
local file. During this merge, conflicts may
occur.
Repository
Read
27The Copy-Modify-Merge Solution
Repository
A new merged file is created on Ariks machine.
28The Copy-Modify-Merge Solution
Repository
Arik commits his file to the repository.
Write
29The Copy-Modify-Merge Solution
Repository
Aviva updates her file from the repository.
Read
30Check-out etiquette
- If two people have a file checked out, they have
to merge their changes before check-in - Merging files can be messy!
- This requires coordination and responsibility on
the part of developers, not to make unnecessary
check-outs, and not to hold check-outs for too
long.
31File Comparison
- Users can graphically compare two versions of
files, in or out of the database. - Tools BeyondCompare, Windiff, AraxisMerge
- This helps with manual merges
- Also helps people decide which version to access
32 SourceSafe
- Central repository of read-only files.
- Everybody sees the same version.
- Only one user can check in at once.
- No branching.
- Limited merge capabilities.
- Synchronized with Visual Studio
33Advantages of SourceSafe
- Synchronized with Visual Studio.
- Relatively inexpensive.
- Relatively simple to administrate.
34Disadvantages of SourceSafe
- Does not support branching
- Requires verbal coordination.
- Poses a problem for large projects.
- Complicates development of features
- Not compatible with other OSs.
35Get Latest Version (?)
- Getting the latest version copies (rather than
links) the file from the database to your
personal directory - And so - Getting latest version overwrites files in
personal folders. - Rename local files beforehand if you want to keep
them. - Database updates do not update local copies.
- Changes to database necessitate manual merges.
36Preserving Database Integrity (or watch
SourceSafe limp)
- Before a SourceSafe check-in
- Verify thoroughly that the modified file works
with other files - Otherwise there could be big trouble
- Other systems allow for new branches
- Files can be updated there.
- Branch is merged with main trunk only after
integrity checks. - Advantage source control throughout the checking
process!
37Demo- SourceSafe
38Concurrent Versions System
- CVS has UNIX origins.
- Available also for Linux and Windows.
- Stores only the differences between versions.
39Clients
- Command line.
- GUI (i.e. WinCVS, tkCVS, etc)
- NOTE Most GUI/Plugins are wrappers around the
basic CVS command line client.
40Revisions
- Each version of a file has a unique Revision
number. Revision numbers look like 1.1, 1.2,
1.3.2.2 or even 1.3.2.2.4.5.
1.1
1.2
1.3
1.4
Main.c
41Revision Numbering
- By default
- revision 1.1 is the first revision of a file.
- Successive revisions incremement the rightmost
number.
42Tags
- Tags are used to give a symbolic name to a
certain collection of file revisions.
1.1
1.2
1.3
1.4
Main.c
TAG_XXX
1.1
1.2
Main.h
1.1
1.2
1.3
Lala.c
43Branching
- Like ClearCase, CVS allows branches
- Allows changes to be isolated into a separate
development line. - Branches are good for
- Fixing bugs in historical releases.
- Developing features without disrupting primary
development.
44Trunks and Branches
- The main branch is called the main trunk.
- A branch can be merged back to the main trunk, or
left as a branch.
45Branches and Revisions
1.2.2.2.2.1
1.2.2.2.2.2
Branch 1.2.2.2.2 -gt
1.2.2.1
1.2.2.2
Branch 1.2.2. -gt
1.1
1.2
1.3
1.4
Main Trunk
Main.h
1.2.4.1
1.2.4.2
1.2.4.3
Branch 1.2.4. -gt
46ClearCase - Overview
- Rational ClearCase is a software tool for
revision - control of source code and other software
- development assets.
- Basic concepts
- Items under ClearCase are generally referred to
- as elements.
- For example
- design models, source files, project files,
DLLs, etc.
47VOB
- All elements stored in VOBs Version Object
Bases. - Depending on the size and complexity of your SW
- development environment ClearCase elements
- may be distributed across more than one VOB.
- For example
- elements used by the Documentation group can be
stored in one VOB, while elements contributing to
software builds can be stored in a different VOB.
48VOB Illustration
-
- This diagram
- illustrates a VOB
- that contains the
- file elements
- prog.c,
- util.h,
- msg.cat,
- and lib.c
49View
- To access an element under ClearCase, you set up
and work in a view, - A view shows a directory tree of specific
versions of the element.
50Two kinds of views
- Snapshot views
- copy files from VOBs to your computer.
- Dynamic views,
- use the multiversion file system (MVFS) of
ClearCase to provide immediate, transparent
access to the data in VOBs.
51Configuration Specifications
- A set of rules called a configuration
specification determines which files are in a
view. - These rules are written in a special and powerful
script language.
52Version Trees
- Each time an element is revised and checked in,
ClearCase creates a new version of the element in
the VOB. - ClearCase organizes the different versions of an
element in a VOB into a version tree.
53Version Trees and Branches - Illustration
- This
- diagram
- illustrates a
- version tree
- and several
- branches
54Advantages of ClearCase
- Can handle projects that
- a) Consists from a lot of developers.
- b) Go on for a very long time.
- Developed and marketed by IBM,
- i.e. very smooth and natural integration with a
lot of other IDE/CM/test/profiling Tools. - Versatile lots of possibilities and
capabilities.
55Advantages cont.
- Supported by multiple OS
- Windows, Unix (Solaris, AIX, ), Linux.
- Can be accessed from client on one OS to a server
on another OS. - Enables real parallel development - work on
multiple versions of the same source file
concurrently.
56Disadvantages
- High price.
- Too versatile
- one can never learn all capabilities.
- Complex support
- must have very good - full time - administrator.
57- ClearCase View Snapshots
- Windows Unix
58ClearCase Integrated in Visual Studio IDE.
59 Checkout Operation Snapshot Windows
Unix
60 ClearCase Merge Utility Windows Unix
61 Version Tree Snapshot Windows
Unix
62General Info Unix version
General information about a file in the
repository in the Unix GUI.
63(No Transcript)
64(No Transcript)
65