Informatics 211: Configuration Management & Coordination

(c) 2007 University of California, Irvine – André van der HoekApril 21, 2023 – 07:58:44 1

Informatics 211:Configuration Management &

Coordination

Informatics 211:Configuration Management &

Coordination

André van der Hoek

University of California, IrvineDonald Bren School of Information and Computer

SciencesDepartment of Informatics

[email protected]


A Simplified Development ScenarioA Simplified Development Scenario

Pete

Pete’s workspace Ellen’s workspace

Ellen

CM repository


Direct ConflictsDirect Conflicts

Conflicting changes to the same artifact

Pete


Ellen

CM repository changeschanges


Indirect ConflictsIndirect Conflicts

Conflicting changes to different artifacts

Pete


Ellen



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]”








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 as of late


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


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


Creating the BaselineCreating the Baseline














Viewing the BaselineViewing the Baseline


Excluding the BaselineExcluding the Baseline


Including the BaselineIncluding the Baseline


Creating the Record SupportCreating the Record Support


Creating the Record SupportCreating the Record Support


Viewing the Record SupportViewing the Record Support


Removing Old ElementsRemoving Old Elements








Adding New ElementsAdding New Elements


Viewing the CD WriterViewing the CD Writer


Trial ProductTrial Product


Pro ProductPro Product


All Music Player Change SetsAll Music Player Change Sets


Visualizing RelationshipsVisualizing Relationships

Change Set

CD Writer

MP3 Encoder

Pro Version

Record Support

Purchase Reminder


Example RelationshipsExample Relationships


Product CompositionsProduct Compositions


Additional RelationshipsAdditional Relationships


Violated RelationshipsViolated Relationships


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


The Eclipse Platform

Event Listeners

CM Plug-in

Workspace

Visualization

Extractor

Internal State

Palantír Client

Analyzer

Visualization

Extractor

Internal State

Palantír Client

Analyzer

Possible Data SourcesPossible Data Sources

Event Database

Palantír Server

BootstrapCapture

Workspace Wrapper

The Eclipse Platform

Event Listeners

CM Plug-in

Workspace

CM System

CM Server

Repository

Pete’s Workspace Ellen’s Workspace

Workspace Wrapper


Workspace Activity ViewerWorkspace Activity Viewer


Three-Dimensional Rotation for Different PerspectivesThree-Dimensional Rotation for Different Perspectives


Some Advanced FeaturesSome Advanced Features


GAIMGAIM


GAIMGAIM


FiltersFilters

Artifact Developer Age Absolute date Artifact pattern Event type Parallelism


GAIM with Artifact Pattern FilterGAIM with Artifact Pattern Filter


GAIM with Additional Age FilterGAIM with Additional Age Filter


GAIM with Additional Parallelism FilterGAIM with Additional Parallelism Filter


Replaying HistoryReplaying History

Extends the usefulness of Workspace Activity Viewer from just understanding the present moment to also beginning to understand how projects evolve

In the following videos, history is partially simulated based on CM archive data


(Scarab Videos)(Scarab Videos)


Indirect ConflictsIndirect Conflicts

Conflicting changes to different artifacts

Pete


Ellen



Traditional CM ApproachesTraditional CM Approaches

Coordination mechanism

Directconflicts

Indirect conflicts

Pessimistic Locking before changes are made

Avoided, at the expense of project delays

Not addressed

Optimistic Automated merging after changes have been made

Resolved, except for overlapping changes

Not addressed


Key ObservationsKey Observations

CM workspaces in reality provide two kinds of isolation– “good” isolation (insulation)

shields developers from parallel changes to artifacts– “bad” isolation (seclusion)

hides knowledge of what artifacts other developers are changing

Opportunities for breaking “bad” isolation are limited– based on repository information only– initiated by developer only– addressing direct conflicts only

In essence, a specific form of coordination is enforced and limited by the process underlying the CM system


Undesirable Consequences (Field Studies)Undesirable Consequences (Field Studies)

The more parallel work takes place, the lower the quality of the code that is delivered

Developers recognize the significance of direct conflicts– direct conflicts are considered “a pain” – developers will race to be the first to commit their

changes, just to avoid the task of merging– much informal communication takes place in order to

attempt to avoid direct conflicts

Developers do not recognize the significance of indirect conflicts– considered to be a normal part of the work (e.g.,

integration, resolving test case failures, dealing with bugs)


Our ObjectiveOur Objective

Support more effective coordination of parallel work by allowing “good” isolation but breaking “bad” isolation

Enable early detection and resolution of direct and indirect conflicts– while these conflicts emerge

Mitigate the impact of direct and indirect conflicts– through provoked self-coordination of developers


Workspace AwarenessWorkspace Awareness

Pete


Ellen

CM repository

changeschanges


Eclipse Visualization: Peripheral IntegrationEclipse Visualization: Peripheral Integration






Three Laboratory ExperimentsThree Laboratory Experiments

Text-based evaluation of the effectiveness of the user interface– Palantír versus no Palantír

Code-based evaluation of the effectiveness of providing awareness information– Palantír versus no Palantír

Code-based evaluation of the effectiveness of providing awareness information on indirect conflicts– Palantír with direct and indirect conflicts versus

Palantír with direct conflicts only


Experiment DesignExperiment Design

Confederate-based design– ensured consistency in number and nature of

conflicts– introduced direct and indirect conflicts– controlled individual differences in project activities

Dependent variables– number of conflicts detected (and resolved)– time-to-completion of tasks– number of coordination attempts


Result 1: Early Conflict Detection and ResolutionResult 1: Early Conflict Detection and Resolution

More direct conflicts were identified and resolved before check-in

More indirect conflicts were identified More indirect conflicts were resolved


Result 2: Indirect Conflict NotificationResult 2: Indirect Conflict Notification

More indirect conflicts were detected and resolved when potential indirect conflicts were highlighted– the indirect conflicts we seeded were easy

Developers’ knowledge of the structure of the code is inadequate to just rely on direct conflict notification


Result 3: Time-to-CompletionResult 3: Time-to-Completion

Direct conflicts– group using Palantír is faster– resolution time for conflict is less

Indirect conflicts– group using Palantír is a little slower– more conflicts are detected and resolved


Result 4: Amount of CommunicationResult 4: Amount of Communication

The use of awareness leads to fewer coordination attempts and less time spent in those attempts– not statistically significant– but sufficiently indicative and sufficiently provocative to

warrant additional study

Text group detect

SCM chat others total

DC CntrlExp

3939

7871

1712

02

9585

IC CntrlExp

538

730

411

09

1150


Interpreting The ResultsInterpreting The Results

Direct and indirect conflicts are detected as they emerge

Developers undertake action upon noticing a potential conflict

Fewer conflicts grow “out of hand” The resulting code is of higher quality The penalty may be a small increase in time

now– but the experiments do not account for the time later

that developers must otherwise spend on resolving conflicts that are committed to the CM repository


Limitations to PalantírLimitations to Palantír

Disconnect between awareness and action Potential for information overload Effective, but not a rich work context

– further examination is required

Opportunities for further improvement and extension are limited by the directory/file metaphor– does not map very well to our mental model of the

code


Lighthouse ApproachLighthouse Approach

Leverage a secondary monitor to provide developers with a coordination platform that integrates awareness and action

Center the platform on the metaphor of emerging design

Contextualize the awareness information based on the changes currently being made


VisionVision


Awareness Information: BasicsAwareness Information: Basics

Emerging design is the design as it resides in the code

Continuously kept up to date with every code change– UML-like diagrams

Keeps the developer abreast of how the code changes at the interface level

OnlineStore

name:String

address:URL

placeOrder(order:Order):void

getQuantity(item:String):int

scan(item:ID):boolean

addItem(item:Item):void

Class


OnlineStore

name:String

address:Address

address:URL

Store

(Store)



(scan(item:ID):boolean)



Class

Awareness Information: BasicsAwareness Information: Basics

Emerging design is the design as it resides in the code

Continuously kept up to date with every code change– UML-like diagrams

Keeps the developer abreast of how the code changes at the interface level


Which Changes by Whom and When?Which Changes by Whom and When?

OnlineStore

name:String

address:Address

address:URL

Store

(Store)






Class


Progression of ChangesProgression of Changes

OnlineStore

name:String

address:Address

address:URL

Store

(Store)






Class


Coordination ActionsCoordination Actions

OnlineStore

name:String

address:Address

address:URL

Store

(Store)






Class





Default: Minimized AppearanceDefault: Minimized Appearance


Two-Stage Auto-Expansion upon ChangesTwo-Stage Auto-Expansion upon Changes


Radial Layout – Code Distance as “Coupling”Radial Layout – Code Distance as “Coupling”






In UseIn Use


Future Plans #1: Design DevationsFuture Plans #1: Design Devations


Future Plans #2: Project ManagementFuture Plans #2: Project Management

Base abstraction upon which to show design deviations,test coverage, code volatility, aging, … – for the entire system


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 developed, 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


AcknowledgmentsAcknowledgments

David Redmiles

Ban Al-Ani

Isabella Almeida Marcelo Alvim

Anita Sarma Chris Van der

Westhuizen Ping Chen Erik Trainer Stephen Quirk Roger Ripley

..and the rest of the Continuous Coordinationresearch group at UC Irvine.

Documents

Informatics 211: Configuration Management & Coordination