300 likes | 481 Views
Palantír: Raising Awareness Among Configuration Management Workspaces. Anita Sarma, Zahra Noroozi, Andr é van der Hoek Department of Informatics & Institute for Software Research University of California, Irvine asarma@ics.uci.edu, znoroozi@yahoo.com, andre@ics.uci.edu.
E N D
Palantír: Raising Awareness Among Configuration Management Workspaces Anita Sarma, Zahra Noroozi, André van der HoekDepartment of Informatics & Institute for Software ResearchUniversity of California, Irvineasarma@ics.uci.edu, znoroozi@yahoo.com, andre@ics.uci.edu
A Typical Development Scenario Pete’s workspace Ellen’s workspace A B C D E C C D C C D CMrepository
Direct Conflicts Pete’s workspace Ellen’s workspace A B C D E C C D C C D CMrepository Conflicting changes to the same artifact
Indirect Conflicts Pete’s workspace Ellen’s workspace A B C D E C C D C C D CMrepository Conflicting changes to different artifacts
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
Approach • Provide continuous workspace awareness • Which artifacts are being changed by whom? • What is the severityof the changes? • What is the impact of the changes? • Design constraints • Non-obtrusiveness • Scalability • Flexibility • Configurability
Palantír Architecture Visualization(s) Visualization(s) Extractor Extractor Internal state Internal state Event service Event wrapper Event wrapper CM client CM server CM client CMrepository Workspace Workspace
Typical Sequence of Events Optimistic • Populated • ChangesInProgress • SeverityChanged • SeverityChanged • … • ChangesCommitted • ChangesInProgress • SeverityChanged • SeverityChanged • … • ChangesCommitted • UnPopulated Pessimistic • Populated • ChangesInProgress • SeverityChanged • SeverityChanged • … • ChangesCommitted • ChangesInProgress • SeverityChanged • 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
Visualization • Tasks • Organize and display events • Same for every CM system • Varying degrees of obtrusiveness • 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
Integration Experience • RCS • Pessimistic CM system • 500 lines of Java code • Single day • CVS • Optimistic CM system • 500 lines of Java code • Single day • JSVN • Optimistic CM system • 500 lines of Java code • Few days
Related Work • CVS and many other CM systems • Only e-mail notifications • Coven • Developers do not know in advance what they will change • BSCW, TUKAN, COOP/Orm • No pair-wise comparisons, no severity measure • State Treemap • No pair-wise comparisons
Conclusions • Palantír is a novel prototype that brings awareness to CM workspaces • Which artifacts are being changed by whom? • What is the severity of the changes? • Push instead of pull • Automated instead of manual • Palantír is independent of the type of CM system used • Palantír was successfully integrated with RCS, CVS, and JSVN
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