informatics 211: configuration management & coordination

Informatics 211:Configuration Management &

Coordination

Informatics 211:Configuration Management &

Coordination

André van der HoekDepartment of Informatics

Donald Bren School of Information and Computer Sciences

University of California, Irvine

[email protected]

A Typical Development ScenarioA Typical Development Scenario

CMrepository

Pete’s workspace

CBA

Ellen’s workspace

E CD

Direct ConflictsDirect Conflicts

CMrepository

Pete’s workspace

BA

Ellen’s workspace

ED

Conflicting changes to the same artifact

CC

Traditional CM TechniquesTraditional CM Techniques

Coordination mechanism

Directconflicts

Pessimistic (classical versioning)

Locking before changes are made

Avoided, at the expense of project delays

Optimistic (advanced versioning)

Automated merging after changes have been made

Resolved, except for overlapping changes

Traditional CM TechniquesTraditional CM Techniques


Directconflicts







Both with the side effect of keeping a history of changes.

Configuration ManagementConfiguration Management

“Configuration management (CM) is a discipline whose goal is to control changes to large software through the functions of: component identification, change tracking, version selection and baselining, software manufacture, and managing simultaneous updates (team work).”

Walter Tichy, SCM-1, 1988

Construction•Building•Snapshots•Regeneration•Optimization


Auditing•History•Traceability•Logging


Components•Versions•Configurations•Baselines•Project contexts


CM Spectrum of FunctionalityCM Spectrum of Functionality

Susan Dart, SCM-3, 1991

Accounting•Statistics•Status•Reports


Process•Lifecycle support•Task mgmt.•Communication•Documentation


Controlling•Access control•Change requests•Bug tracking•Partitioning


Team•Workspaces•Merging•Families


Structure•System model•Interfaces•Consistency•Selection


CCC/Harvest

Three Generations of CM SystemsThree Generations of CM SystemsFu

nct

ionalit

y Proteus

Jasmine

EPOS

VOODOO

ShapeTools

Asgard NUCMDaSC

Vesta

Adele

ICE

Odin

Time

Source Integrity

Continuus

CVS

PVCSDSEE

SCCS

NSE

ClearCase

TRUEchangeSerena

Endevor

Perforce

RCSSablime Research

Development

First GenerationFirst Generation

Focused on:– archiving individual elements– strictly avoiding conflicts

Characterized by:– simple, separate tools– development orientation

Canonical examples– SCCS– RCS– Make

First Generation: Version GraphsFirst Generation: Version Graphs

1.0

1.1

2.0

1.2

2.1

1.2.1.0

1.2.1.1

Author = “André v/d Hoek”Date = 01/12/2001Time = 7:52amComment = “Trying new stuff”Lock = “[email protected]”

lock







First GenerationFirst Generation











Second GenerationSecond Generation

Focused on:– archiving compound elements– different version models

Characterized by:– integrated versioning & build tools– development orientation

Canonical examples:– CVS– Subversion– PVCS– SourceSafe

Four Canonical Version ModelsFour Canonical Version Models

State-based extensional– version tree

State-based intensional– conditional compilation

Change-based extensional– change packages

Change-based intensional– change sets

Conditional CompilationConditional Compilation

…#ifdef UNIX

#include <stdio.h>#endif#ifdef GRAPHICS

#include <graphics.h>#ifdef SMARTGRAPHICS

#include <smart.>#endif

#endif…

Change PackagesChange Packages

1.0

1.1

2.0

1.2

2.1

1.2.1.0

1.2.1.1

1.0

2.0

2.2

2.1

2.3

1.0

1.1

1.3

1.2

2.0

2.0.1.0

1.0

1.1

1.2

Change SetsChange Sets

Baseline

Bug fix #16

Feature addition#103

Bug fix #17Feature addition

#104

Bug fix #8

Bug fix #16

Bug fix #6

Bug fix #21

AVAILABLECHANGE

SETS

SYSTEMSELECTION







Second GenerationSecond Generation











Third GenerationThird Generation

Focused on:– providing process support– being all-encompassing

Characterized by:– large, complex tools– management orientation

Canonical examples:– ClearCase together with ClearGuide– Cm/Synergy







Third GenerationThird Generation











A Fourth GenerationA Fourth Generation

?

No…No…

CM core functionality is stable with well-understood choices

CM tool enhancement seems to be limited to feature creep, not fundamental new approaches

SCM workshop series has ended Only a few pure CM papers are being

published to date

Maybe…Maybe…

CM functionality is now appearing in domains other than source code management– web content management– product data management– web services and components– software deployment– product line architectures– …

Mining software repositories– no better repository than the CM repository

Still some problems left– indirect conflicts– concern management

Coordination

Software Deployment: the ProblemSoftware Deployment: the Problem

Producer Consumer

Software Deployment Life CycleSoftware Deployment Life Cycle

Release

Retire

Reconfig Adapt RemoveUpdate

Install

Producer

Consumer

SourceForgeSourceForge

RPMRPM

Product Line Architectures: The ProblemProduct Line Architectures: The Problem

“A software product line (SPL) is a strategic software-based asset that explicitly recognizes, optimizes, and manages variability towards current and future feature changes.” [van der Hoek]

But how to manage this asset?

Classic Versioning for Product LinesClassic Versioning for Product Lines

Advanced Versioning for Product LinesAdvanced Versioning for Product Lines

Mining Software RepositoriesMining Software Repositories

Configuration management repositories are traditionally a “depot”– occasional roll-back– occasional search for relevant information

But what if we used the information captured by configuration management repositories to our advantage– understanding software developers– helping software developers

Activity ViewerActivity Viewer

HighlightingHighlighting

Distance is AgeDistance is Age

Rotation Allows Different ViewpointsRotation Allows Different Viewpoints

Larger Projects: Time OrderedLarger Projects: Time Ordered

Larger Projects: Most Activity OrderedLarger Projects: Most Activity Ordered

Larger Projects: Developer ViewLarger Projects: Developer View

Same Project Ordered by TimeSame Project Ordered by Time

Committed versus Not CommittedCommitted versus Not Committed

(Animated)(Animated)

Applied to GAIM, jEdit, and Argo/UMLApplied to GAIM, jEdit, and Argo/UML

Simulated the archives– demonstrated scalability– demonstrated usefulness– filters are a must

Interesting patterns– core developers– core developer “overtaken” by others– lots of people on a project, but most are working on

pictures, not code– highly active artifacts– …

Much more analysis to be done Planned: viewing on HIPerWall

Indirect ConflictsIndirect Conflicts


Directconflicts

Indirect conflicts




Not addressed




Not addressed

Direct ConflictsDirect Conflicts

CMrepository

Pete’s workspace

BA

Ellen’s workspace

ED

Conflicting changes to the same artifact

CC

Indirect ConflictsIndirect Conflicts

CMrepository

Pete’s workspace

CBA

Ellen’s workspace

E CD

Conflicting changes to different artifacts

PalantírPalantír

LighthouseLighthouse

World ViewWorld View

World Wall?World Wall?

CoordinationCoordination

Asynchronous communicationAccess to common set of artifacts,

isolated workspaces and version control

Parallel development,roles and access rights

Passive awareness ofdevelopment activities

and developers, manageinformation overload

Task allocation and assignment

Communication archivalalong with artifacts

Communication

Collocation benefits todistributed development

Organizational memory,knowledge acquisition and

dissemination, social navigation

Prescribed and defined coordination support

Artifact Management Task Management

Advanced conflictdetection

Bas

ic F

unct

iona

lity

Rig

id P

roce

ssIn

form

atio

n D

isco

very

Info

rmat

ion

Pro

visi

on

Fine grained versioning,conflict resolution

Instant messaging,monitoring changes

to artifacts

Layers: Coordination ParadigmsLayers: Coordination Paradigms








Communication







Bas

ic F

unct

iona

lity

Rig

id P

roce

ssIn

form

atio

n D

isco

very

Info

rmat

ion

Pro

visi

on



to artifacts

Strands: Technical Dimensions of CoordinationStrands: Technical Dimensions of Coordination








Communication







Bas

ic F

unct

iona

lity

Rig

id P

roce

ssIn

form

atio

n D

isco

very

Info

rmat

ion

Pro

visi

on



to artifacts

A New Paradigm: Provoked BehaviorA New Paradigm: Provoked Behavior

Continuous coordination,collaborative architecture,

seamless development environments,








Communication







Bas

ic F

unct

iona

lity

Rig

id P

roce

ssIn

form

atio

n D

isco

very

Info

rmat

ion

Pro

visi

onP

rovo

ked

Beh

avio

r



to artifacts

Configuration ManagementConfiguration Management

Continuous coordination,collaborative architecture,

seamless development environments,








Communication







Bas

ic F

unct

iona

lity

Rig

id P

roce

ssIn

form

atio

n D

isco

very

Info

rmat

ion

Pro

visi

on



to artifacts

Pro

voke

dB

ehav

ior

ConclusionConclusion

CM is a long-standing field which has seen numerous contributions– some highly influential (sometimes delayed by as much as

20 years)– others indirectly shaping– others utterly useless

While the core ideas of CM have been well developer, there is still much room for improvement– particularly if one considers CM to be a coordination

problem– particularly if one brings together CM with other disciplines

Software engineering can be cool

informatics 211: configuration management & coordination

Documents

setsbaselinebug fix

version graphs1

version selection

endif change packages1

history of changes

ifdef unix

ifdef smartgraphics

ifdef graphics