Palantír: Coordinating Distributed CM Workspaces

1. Palantír: CoordinatingDistributed CM Workspaces Anita Sarma, André van der Hoek Institute for Software ResearchUniversity of California, Irvine{asarma, andre}@ics.uci.edu

2. Pete’s workspace Ellen’s workspace A B C D E C A Typical Development Scenario CMrepository

3. Problem! • A CM workspace in reality provides two kinds of isolation: • Good isolation • Shields current work from others changes • Bad isolation • Hides 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

4. CM repository CM repository The 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

5. Many 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!

6. Pete’sVisualizations Ellen’sVisualizations Event wrapper Event wrapper Event wrapper CM client CM server CM client Pete’s workspace Ellen’s workspace D E C A C B Palantír Architecture Event Service Palantír Internal State Palantír Internal State CMrepository

7. Populating a Workspace Ellen populates her workspace withdirectories & files

8. Making Changes in the Workspace • Ellen makes changes • edit – creates redo.c • write.c & dict.c • ‘?’ denotes artifacts are • undergoing changes • Green color denotes • changes by workspace • owner

9. Committing Changes Ellen has finished her changes and committed them ‘?’ has changed to ‘!’ denoting changes are known Blue bars denote Severity of changes

10. More Changes (by Other Developers) Layers denote concurrent changes Other authors denoted by shades of red color Layers can be brought forward

11. Critical Feature: Pair-Wise Comparisons

12. Removing and Moving Artifacts Icons denote CM activities namely move and remove

13. Metadata Extensive metadata from CM systems Annotated with time of event occurrence Choice of author color from palette Back/ forward button for easy traversal

14. Scalability & 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

15. Experience • 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

16. Related Work • Configuration Management • Coven • COOP/Orm • CSCW • MMM, ShrEdit • BSCW, “Edit wear and read wear” • Software Evolution Visualization • Code decay • 3D visualization

17. Conclusions • 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

19. 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.”

20. Conflicts • 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

21. Agile 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)

22. Event 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

23. Existing 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

24. Groove Siena Siena Clients listening to events P2P

25. dev1-dev2 dev 2 dev1-dev3 dev1-dev4 dev1-All dev 1 ws owner dev 4 Pair-Wise Comparisons dev 3 dev1-All: summarizes all comaprisons dev1-dev?: only those conflicts between dev1 and the other dev

26. Visualization 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