Configuration Management Workspace Awareness for Distributed Software Development

1. Configuration Management Workspace Awareness for Distributed Software Development Anita SarmaDepartment of Informatics & Institute for Software ResearchUniversity of California, Irvineasarma@ics.uci.edu www.ics.uci.edu/~asarma Faculty Advisor: André van der Hoek

2. Overview • Topic: Awareness in Configuration Management • Status: • Passed qualifying exam • Currently working on survey • Need to complete • Survey • Topic proposal • Final defense • Estimated Graduation Date: Nooit • Plans after graduation: ?

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

4. 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

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

6. 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

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

8. Approach • Provide continuous workspace awareness • Which artifacts are being changed by whom? • What is the severityand impact of the changes? • Design constraints • Non-obtrusiveness • Flexibility • Configurability • Scalability

9. Palantír Architecture Visualizations Visualizations Extractor Extractor Internal state Internal state Event service Event wrapper Event wrapper CM client CM server CM client CMrepository Workspace Workspace

10. Palantír Components • Extractor • 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 • Internal State • 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

11. Palantír Components cont.. • Extractor • Further narrow down the events to be viewed • Set of workspaces • Set of authors • Set of artifacts • Visualizations • Organize and display events • Varying degrees of obtrusiveness • Ticker tape • Tabular • Explorer • Fully graphical

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

13. 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

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

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

16. Critical Feature: Pair-Wise Comparisons

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

18. Visualizations

19. Work to Date • Basic infrastructure is in place • Four visualizations created • Integrated with three CM systems (RCS, CVS, Subversion) • Addressed the design constraints • But still need to address scalability further

20. Current Research Plan • Research Question: Can Palantír provide more detailed and precise information such that developers can better coordinate their parallel activities? • Key Insight: Incorporate analysis in Palantír • Approach: Calculate and present severity and impact of changes • Evaluation: Case study Palantír in actual development setting

21. Severity Analysis • “The amount (size) of change between two versions of an artifact” • Currently calculated as the percentage of lines of code that have changed, a simple but not completely accurate measure • Proposed algorithms • Token based difference • Measures structural changes, but language dependent • Abstract syntax tree • Very detailed analyses, but likely too expensive (and language dependent) • Fits easily into the infrastructure

22. Impact Analysis • “The effect of changes on my current work(space)” • Proposed algorithms • Overlapping lines of code • Simple, but inaccurate • Changed interfaces • Potentially accurate and effective, but language dependent • Dependency analysis • Very precise, semantic results, but complex (and language dependent) • Does not fit easily in the infrastructure

23. Evaluation • Case study to determine the effectiveness of Palantír • Does it reduce the number of conflicts? • Does it speed up development time? • Does it improve coordination? • Does it scale? • Comparison • Current prototype in a real development scenario to determine baseline information • Palantír as enhanced with advanced severity and change impact measures to determine the effectiveness of these measures in conflict detection

24. Back-Up Evaluation • Simulate an actual development environment • Obtain a representative CM archive • “Run” through Palantír • Compare actual problems with highlighted problems

25. Conclusions • We have demonstrated the feasibility of a novel approach to increasing workspace awareness with a basic prototype of Palantír • We have to determine which measures of severity and impact analysis we can use • Determine which of these measures are accurate in highlighting potential conflicts • Evaluate Palantír to determine its effective-ness in reducing conflicts in software development

26. Related Work • Configuration Management Systems • CVS and many other CM systems • Only e-mail notifications • Coven • Developers do not know in advance what they will change • Night Watch • Cover

27. Related Work cont.. • In the area of CSCW • BSCW, TUKAN, COOP/Orm • No pair-wise comparisons, no severity measure • State Treemap • No pair-wise comparisons • Sepia

28. Acknowledgements • Effort funded by the National Science Foundation under grant numbers CCR-0093489 and IIS-0205724. • Special thanks to undergraduates • Peggy Lin • Zahra Noorozi