Palantr: Coordinating Distributed CMWorkspaces

1
Palantír CoordinatingDistributed CM Workspaces

• Anita Sarma, André van der Hoek Institute for
  Software ResearchUniversity of California,
  Irvineasarma, andre_at_ics.uci.edu

2
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 others changes, but current work
remains shielded from other peoples changes
4
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
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

18
(No Transcript)
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
• Elvins 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
P2P

• Groove

• Siena

25
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