palantír: coordinating distributed cmworkspaces

26
Palantír: Coordinating Distributed CM Workspaces Anita Sarma, André van der Hoek Institute for Software Research University of California, Irvine {asarma, andre}@ics.uci.edu

Upload: luana

Post on 21-Jan-2016

33 views

Category:

Documents


0 download

DESCRIPTION

Palantír: Coordinating Distributed CMWorkspaces. Anita Sarma, André van der Hoek Institute for Software Research University of California, Irvine {asarma, andre}@ics.uci.edu. Pete’s workspace. Ellen’s workspace. A. B. C. D. E. C. A Typical Development Scenario. CM repository. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Palantír: Coordinating Distributed CMWorkspaces

Palantír: CoordinatingDistributed CM Workspaces

Palantír: CoordinatingDistributed CM Workspaces

Anita Sarma, André van der Hoek Institute for Software ResearchUniversity of California, Irvine

{asarma, andre}@ics.uci.edu

Page 2: Palantír: Coordinating Distributed CMWorkspaces

A Typical Development ScenarioA Typical Development Scenario

CMrepository

Pete’s workspace

CBA

Ellen’s workspace

E CD

Page 3: Palantír: Coordinating Distributed CMWorkspaces

Problem!Problem!

A CM workspace in reality provides two kinds of isolation:– Good isolation

Shields current work from others changes

– Bad isolationHides knowledge of what artifacts other

developers are changing

Break bad isolation, such that developers are aware of each other’s changes, but current work remains shielded from other people’s changes

Page 4: Palantír: Coordinating Distributed CMWorkspaces

The SolutionThe 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 explicitlyrequest information

CMrepository

CMrepository

Page 5: Palantír: Coordinating Distributed CMWorkspaces

Many Difficult QuestionsMany Difficult Questions

Which information must be shared? How is the information presented? How can information overload be

avoided? Can this approach scale? Does it actually help developers

coordinate better?

Goal: demonstrate feasibility of workspace awareness first!

Page 6: Palantír: Coordinating Distributed CMWorkspaces

Palantír ArchitecturePalantír Architecture

CMrepositoryPete’s workspace

CBAEllen’s workspace

E CD

CM client CM server CM client

Event wrapper Event wrapper Event wrapper

Pete’sVisualizations

Ellen’sVisualizations

PalantírInternal State

PalantírInternal State

Event Service

Event Service

Page 7: Palantír: Coordinating Distributed CMWorkspaces

Populating a WorkspacePopulating a Workspace

Ellen populatesher workspace withdirectories & files

Page 8: Palantír: Coordinating Distributed CMWorkspaces

Making Changes in the WorkspaceMaking Changes in the Workspace

Ellen makes changes• edit – creates redo.c• write.c & dict.c

‘?’ denotes artifacts are undergoing changes

Green color denoteschanges by workspaceowner

Page 9: Palantír: Coordinating Distributed CMWorkspaces

Committing ChangesCommitting Changes

Ellen has finishedher changes and committed them

‘?’ has changed to ‘!’denoting changes areknown

Blue bars denoteSeverity of changes

Page 10: Palantír: Coordinating Distributed CMWorkspaces

More Changes (by Other Developers)More Changes (by Other Developers)

Layers denote concurrent changes

Other authors denotedby shades of red color

Layers can be broughtforward

Page 11: Palantír: Coordinating Distributed CMWorkspaces

Critical Feature: Pair-Wise ComparisonsCritical Feature: Pair-Wise Comparisons

Page 12: Palantír: Coordinating Distributed CMWorkspaces

Removing and Moving ArtifactsRemoving and Moving Artifacts

Icons denote CM activitiesnamely move and remove

Page 13: Palantír: Coordinating Distributed CMWorkspaces

MetadataMetadata

Extensive metadata fromCM systems

Annotated with time of event occurrence

Choice of author colorfrom palette

Back/ forward buttonfor easy traversal

Page 14: Palantír: Coordinating Distributed CMWorkspaces

Scalability & Information OverloadScalability & Information Overload

Application– Manage only relevant artifacts

Artifacts present in “my” workspace Leverages event service filtering

– Internal data structure versus visualization User cognition

– Pair-wise comparisons– Stack shows linear evolution in time– Filter data per user criteria– Sorting of artifacts per severity / date

Page 15: Palantír: Coordinating Distributed CMWorkspaces

ExperienceExperience

Integration with two CM systems– CVS (optimistic)– RCS (pessimistic)

Relatively easy to implement– 500 lines of Java code each– Wraps each CVS/RCS command with a

PalantirCVS/RCS command that invokes CVS/RCS and emits relevant events

– Not complete, but the essence (~60%) is there

Page 16: Palantír: Coordinating Distributed CMWorkspaces

Related WorkRelated Work

Configuration Management– Coven– COOP/Orm

CSCW– MMM, ShrEdit– BSCW, “Edit wear and read wear”

Software Evolution Visualization– Code decay– 3D visualization

Page 17: Palantír: Coordinating Distributed CMWorkspaces

ConclusionsConclusions

Palantír is a prototype that…– …brings awareness to distributed CM

workspaces– …shows pair-wise conflict – …provides a simple measure of severity

Future Work– Examine change impact analysis for both

atomic and compound artifacts– Additional visualizations– Case studies to determine effectiveness

Page 18: Palantír: Coordinating Distributed CMWorkspaces
Page 19: Palantír: Coordinating Distributed CMWorkspaces

Conflicts Do Happen!Conflicts Do Happen!

Large systems, multiple developers lead to conflicting changes.

Perry & Votta: “Files that have high degrees of parallel changes also tend to have more defects.”

Perry & Votta: “Overlapping time schedule of successive releases suggest that features for different releases are being developed almost concurrently.”

Awareness of others changes helps in conflict resolution– Elvin’s success: “providing a way to gather and

redistribute collaboration-focused information during everyday use.”

Page 20: Palantír: Coordinating Distributed CMWorkspaces

ConflictsConflicts

Direct Conflicts: Overlapping changes to the same artifact

Indirect Conflicts: Changes to one artifact modifying the behavior of another artifact– Implicit domain knowledge of developers.– Future Work: trace dependencies

Page 21: Palantír: Coordinating Distributed CMWorkspaces

Agile ProcessesAgile Processes

Agile processes have fewer conflicts, but conflicts exist nonetheless

Increased awareness necessitated by higher number of check-ins– Need to synchronize workspace only for

significant changes, and not for all changes in the workspace

A number of organizations, do not follow agile processes (NASA)

Page 22: Palantír: Coordinating Distributed CMWorkspaces

Event FrequencyEvent Frequency

Event generated on check-in / check-out and other CM functions– Depending on the CM system in question.

Push Model: events generated when others perform CM operations.

Potential to leverage virtual file systems– Track smaller units of changes (save /edit)

Especially for severity calculations

– Develop simple watch mechanisms

Page 23: Palantír: Coordinating Distributed CMWorkspaces

Existing CM functionalityExisting CM functionality

CVS watches– E-mail delivery mechanism is crude– Scaling problems

Coven softlocks– Need to specify intended changes

beforehand, which is difficult to do– Only watches for direct conflicts

Page 24: Palantír: Coordinating Distributed CMWorkspaces

P2PP2P

Groove Siena

SienaSiena

Clients listening to events

Page 25: Palantír: Coordinating Distributed CMWorkspaces

Pair-Wise ComparisonsPair-Wise Comparisons

dev 3

dev 1ws owner

dev 2

dev 4

dev1-dev2

dev1-dev3

dev1-dev4

dev1-All

dev1-All: summarizes all comaprisons

dev1-dev?: only those conflicts between dev1 and the other dev

Page 26: Palantír: Coordinating Distributed CMWorkspaces

Visualization FeaturesVisualization Features

Different views with different trade-offs– Amount of information versus level of intrusiveness– Scrolling marquee, fully graphical, tabular

Configurable– Selection of relevant developers, events, timeframes

Scalable– Internal data structure versus actual visualization– Pair-wise conflicts– Filter data on user criteria – Sorting per severity or change impact

Extensive metadata