Community, Artifacts, and Versions André van der Hoek Institute for Software Research University of California, Irvine

Community Set of people working together towards a common goal Here, we concern ourselves to those communities that are involved in the joint production of artifacts Intrinsic need: coordination

Limitations in Coordination Ability Group size Location of group members Technology Artifacts

Conceptual VisualizationStrengthsWeaknesses Formal, process- based coordination Scalable; Control; Insulation from other activities; Group-centric Resynchronization problems; Insulation becomes isolation Informal, awareness- based coordination Flexible; Promotes synergy; Raises awareness; User-centric Not scalable; Requires extensive human intermediation Typical Coordination Mechanisms

Conceptual VisualizationStrengthsWeaknesses Formal, process- based coordination Scalable; Control; Insulation from other activities; Group-centric Resynchronization problems; Insulation becomes isolation Informal, awareness- based coordination Flexible; Promotes synergy; Raises awareness; User-centric Not scalable; Requires extensive human intermediation Continuous coordination Expected to be the strengths of both formal and informal coordination To be discovered by the proposed research Continuous Coordination

Configuration 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 Construction Building Snapshots Regeneration Optimization Auditing History Traceability Logging Auditing History Traceability Logging Components Versions Configurations Baselines Project contexts Components Versions Configurations Baselines Project contexts Spectrum of Functionality Susan Dart, SCM-3, 1991 Accounting Statistics Status Reports Accounting Statistics Status Reports Process Lifecycle Task mgmt. Communication Documentation Process Lifecycle Task mgmt. Communication Documentation Controlling Access control Change request Bug tracking Partitioning Controlling Access control Change request Bug tracking Partitioning Team Workspaces Merging Families Team Workspaces Merging Families Structure System model Interfaces Consistency Selection Structure System model Interfaces Consistency Selection

Three Generations of CM Systems Functionality Time Research Development 1 st : version control 2 nd : configuration management 3 rd : process-based CM

A Typical Development Scenario CM repository Pete’s workspace CBA Ellen’s workspace ECD CD D C C

Direct Conflicts CM repository Pete’s workspace CBA Ellen’s workspace ECD Conflicting changes to the same artifact CC C D D

Indirect Conflicts CM repository Pete’s workspace CBA Ellen’s workspace ECD Conflicting changes to different artifacts CC C D D

Traditional CM Approaches Coordination mechanism Direct conflicts Indirect conflicts PessimisticLocking before changes are made Avoided, at the expense of project delays Not addressed OptimisticAutomated merging after changes have been made Resolved, except for overlapping changes Not addressed

Key Observations A CM workspace in reality provides two kinds of isolation: –Good isolation  Shields developers from parallel changes to artifacts –Bad isolation  Hides knowledge of what artifacts other developers are changing Opportunities for breaking isolation are limited –Based on repository information only –Initiated by developer only –Addressing direct conflicts only

Objective To increase awareness of ongoing workspace activities –Collect –Distribute –Organize –Present To do so automatically and continuously –Push information To, thereby, move earlier the point at which potential direct and indirect conflicts can be detected

Solution New situation: Share information when others perform CM operations, and not just when I perform a CM operation Old situation: Information available only when I carry out a CM operation or explicitly request information CM repository CM repository

Palantír Architecture CM repository Workspace Event wrapper Event service CM clientCM serverCM client Visualization(s) Event wrapper Internal state Extractor Visualization(s) Internal state Extractor

Event TypeIndication PopulatedArtifact has been placed in a workspace UnpopulatedArtifact has been removed from a workspace SynchronizedArtifact has been synchronized with repository ChangesInProgressArtifact has changed in a workspace ChangesCommittedArtifact has been stored in repository ChangesRevertedArtifact has been returned to its original state AddedNew artifact has been added to workspace RemovedArtifact has been removed from workspace RenamedArtifact has been renamed MovedArtifact has been moved from one artifact to another SeverityChangedSeverity of changes to an artifact has changed Types of Events

Typical Sequence of Events Pessimistic Populated ChangesInProgress SeverityChanged … ChangesCommitted ChangesInProgress SeverityChanged … ChangesCommitted UnPopulated Optimistic Populated ChangesInProgress SeverityChanged … ChangesCommitted ChangesInProgress SeverityChanged … ChangesCommitted UnPopulated

Event Wrapper Tasks –Intercept workspace activity –Interpret workspace activity –Determine whether the activity is relevant to Palantír –If relevant, gather information regarding the activity –Construct and emit one or more events Unique per CM system –Wrap command line –Use standard facilities (triggers, virtual file system) Can and should remain unobtrusive

Internal State Tasks –Maintain overview of activities in both the local and remote workspaces –Subscribe to relevant workspace activities  Those pertaining to the artifacts in the local workspace but occurring in other workspaces  Siena-based event routing –Bootstrap new workspaces with information on existing workspaces Same for every CM system Always remains unobtrusive

Extractor Tasks –Further narrow down the events to be viewed  Set of workspaces  Set of authors  Set of artifacts  … Same for every CM system One-time obtrusive

Extractor

Visualization Tasks –Organize and display events Same for every CM system Varying degrees of obtrusiveness –Ticker tape –Tabular –Explorer –Fully graphical

Ticker Tape

Tabular

Explorer

Fully Graphical

Severity Currently calculated as the percentage of lines of code that have changed –Simple –Not completely accurate  1 line change to an interface  1000 lines renaming a variable Work in progress –Other severity measures –Impact measures

Continuous Coordination Palantír addresses the first part of continuous coordination: information exchange and awareness Palantír still needs to address the second part of continuous coordination: allowing developers to act upon the information –Part is done subconsciously –Part should be supported explicitly

Conclusions Palantír is a novel prototype that raises awareness of workspace activities –Maintains good isolation while overcoming bad isolation –Based on workspace information –Automated (push instead of pull) –Addressing direct and indirect conflicts Palantír is a demonstration of continuous coordination, combining formal (CM system check-in/check-out) with information (awareness) mechanisms –Can we extend the same principles to other activities (e.g., design, …)?

Future Work Case study to determine the effectiveness of Palantír –Does it reduce the number of conflicts? –Does it improve coordination? –Does it speed up development time? Further support for indirect conflicts –Impact analysis –Dependencies Develop additional visualizations