Configuration Management and Distributed Software Engineering :COORDINATION

By June 20, 2015


Since a shared set of objects reside at the heart of any collaborative system, some mechanism must be in place to coordinate the activities of the multiple users within the system. The more general computer-supported collaborative-work (CSCW) research supports the approaches taken in collaborative software engineering coordination approaches. Traditionally in software engineering, one of two approaches is taken with regard to coordination: pessimistic locking and optimistic sharing.

Thus assume the scenario in the figure below where a shared document within the software engineering code repository is accessed by two users. If the original version of the document (A) is edited by both users 1 and 2, and both users desire to commit their changes to the shared space, then a collision occurs and resolution is needed. Should user 1’s changes be committed; should user 2’s changes be committed; or should some common version that incorporates both sets of changes be committed?

Distributed version control can be approached via three main models: turn taking, split-combine, and copy-merge. All have advantages and disadvantages.

The turn taking approach to collaborative development suffers from the fact that only one participant can edit the document at any given time; this reduces the parallel nature of collaborative development. The split-combine approach assumes that the splits can be static and that there is very little interaction among participants; this is often not the case as different sections of a system can be tightly coupled and dependant upon each other. The copy-merge approach has a high degree of parallelism in the sense that all participants can edit the files/documents at the same time, but the merge step of combining all of these changes can become quite difficult and costly [Magnusson et al. 1993].

Configuration management systems typically take one of two approaches with regard to locking: optimistic or pessimistic locking. In the optimistic approach, developers are free to develop in a more parallel fashion, but conflict occurs at the merge point when two sets of files must be merged together and changes brought together (and avoid losing work and ensuring that changes in one file have not adversely affected changes in the other file). In the pessimistic approach, developers must obtain a lock on a file before being able to edit it; this can reduce the parallel nature of development since at most one developer can edit the file at any time.

Both optimistic and pessimistic configuration management rely upon the user to query the CMS as to the state of the file; a better approach would be one in which the emphasis shifts to a “push” information flow where the system updates the user as to who is also interacting with the files that they are interested in. Palantir [Sarma et al. 2003] is one such system that takes an active role in informing users of changes and graphically depicts a heuristic measure of the severity of change with respect to the users’ local copy of the file.