Operation-based revision control systems

Haifeng Shen and Chengzheng Sun

School of Computing and Information Technology
Griffith University
Brisbane, QLD 4111, Australia
{Hf.Shen, C.Sun}@cit.gu.edu.au

ABSTRACT operation O2 = Ins[5, ‘B’] is performed to insert the

In this paper, we will present some major drawbacks in character ‘B’ at the beginning of the second line. After the
state-based revision control systems and explain why execution of O2 , the first line remains A111 and the
operation-based revision control systems can overcome second line becomes B222. At this time, the user decides
these drawbacks. We further point out that operation- to check his working copy into the repository. That is to
based revision control systems can ease the smooth switch say, changes made in his working copy will be merged
between asynchronous and synchronous collaboration into the copy in the repository.
modes. Finally issues in operation-based revision control
systems will be raised and we are working on these issues
to make operation-based revision control systems feasible A111
and usable. B222
KEYWORDS
Revision control systems, state-based merging, and O ' 1 = D el[0, 9] O ' 2 = Ins [0, "A111\nB222"]
operation-based merging
INTRODUCTION 111 c hec kout
It is very common that more than one software developer 222
is involved in the development of a large software project. Repos itory
These developers could simultaneously modify the same W orking c opy
or different modules of the code. To support this kind of 111
software development, some sort of configuration 222
management tool or revision control system is needed to
support collaboration among developers. Revision control O 1 = Ins [0, 'A']
systems usually work in the manner of Copy-Modify-
Merge (CMM) [2]. Concretely speaking, each collaborator A111
checks out a separate working copy of the code from a 222
central repository, then modifies the copy, and finally O 2 = Ins [5, 'B']
checks the copy into the repository to form a new version.
Changes made in the working copy will be merged into A111
another working copy when another collaborator updates B222
his working copy with the new version in the repository.
There are lots of revision control systems available, such c hec kin
as RCS [15], CVS [3], SourceForge [11], and Visual
SourceSafe [16]. Common features in these systems are: F ig 1 S tate-bas ed m erging
1) all of them are based on CMM paradigm; 2) all of them
only support asynchronous collaboration; 3) all of them The state-based merging process does not use the
employ state-based merging [6]. information that evolution from the initial document state
(111 and 222) to the final document state (A111 and
Let’s use a concrete example to explain what is state- B222) is caused by the execution of operations O1 and
based merging. Look at the example in Fig 1. A document
O2 . Instead, the merging process compares the initial and
in the repository contains two lines: 111 and 222. A user
the final document states to compute the differences
checks out a working copy to his working directory and
between them and to generate an edit script by the
starts modifying. Firstly, operation O1 = Ins[0, ‘A’] is
execution of which a new version will be generated in the
performed to insert the character ‘A’ at the beginning of repository to accommodate all changes made in the
the first line. After the execution of O1 , the first line working copy. The edit script includes O'1 = Del[0, 9] to
becomes A111 and the second line remains 222. Then

1
delete both lines and O' 2 = Ins[0, “A111\nB222”] to
insert two new lines. We can see that the edit script, which
can be regarded as artificial operations to produce the
final state from the initial state, is totally different from
the actually performed operations. Furthermore, the edit
script is far more coarse-grained than actually performed
operations. In other words, the edit script is line based
while actually performed operations are position based
(i.e., actually performed operations could target at any
position within a line).
Operation-based merging [6], however, directly applies
actually performed operations (i.e., O1 and O2 in this
example) to the copy in the repository to generate a new
version that accommodates all changes made in the
working copy.
In terms of different merging approaches, we classify
revision control systems into state-based and operation-
based revision control systems. The following two
sections present drawbacks in the state-based revision
control systems from the perspectives of external
functionality and internal implementation respectively.
Then we further argue that operation-based revision
control systems can ease the smooth switch between
asynchronous and synchronous collaboration modes.
Before giving concrete future work and summarizing the
paper, we raise some major issues in operation-based
revision control systems.
EXTERNAL FUNCTIONALITY
1. Extensibility
A state-based revision control system relies on some sort
of text differentiation tool, such as diff [8], to generate an
edit script between two document states. This limitation
constrains a state-based revision control system only
applicable for text documents. In contrast, an operation-
based revision control system only requires actually
performed operations and it doesn’t matter whether these
operations are generated from text objects. Therefore,
operation-based revision control systems can be extended
to manage any type of document.
2. Merging limitation
An edit script is line-based. Therefore changes made
within the same line by different users cannot be merged.
In practice, in CVS [3], even changes made in adjacent
lines cannot be merged. It was argued that concurrent
changes within the same line are very rare in real life and
it would also be easy to manually merge those changes if
concurrent changes have been made within the same or
adjacent lines. It could be rare that concurrent changes are
made within the same line. However, concurrent changes
within the same block are not rare at all. For example,
two authors are jointly writing a paper. When the deadline
approaches, they decide to concurrently finalize the paper
by taking different roles. Author 1 is responsible for
correcting spell and grammar errors while Author 2 is
responsible for adding references in the paper. Suppose
Author 1 has performed at least one operation in each of
20 consecutive lines and Author 2 has added several
references in some 10 of these 20 lines. When they come
to reconcile their work, changes made by Author 1 and
Author 2 in these 20 lines cannot be merged although we
know their changes do not conflict at all. Manual merging
would be very painful because changes made by one of
them have to be redone. The root of the problem is coarse-
grained edit scripts dramatically increase the chance of
overlapping conflicts although actually performed
operations do not overlap at all.
In contrast, an actually performed operation is fine-
grained in the sense that it can target at any position in the
document. Therefore overlapping conflict between a pair
of actually performed operations is very rare. Moreover,
theoretically, any overlapping conflict can be syntactically
resolved by some sort of mechanism like operational
transformation [13] or multiple versioning [14]. Therefore
operation-based revision control systems can syntactically
merge any changes made at any position in the document.
On the other hand, some sort of conflict resolution
mechanism is certainly indispensable to solve potential
semantic conflicts. In the previous example, changes made
by Author 1 and Author 2 should be able to be
automatically merged in operation-based revision control
systems because their operations do not overlap at all and
there is no potential semantic conflict either.
3. Conflict resolution
Human intervention for conflict resolution in both revision
control systems is inevitable. State-based revision control
systems can solve neither syntax nor semantics conflicts.
Although syntax conflicts can be automatically solved in
operation-based revision control systems as mentioned
before, potential semantic conflicts still need human
intervention. State-based merging can provide no help for
human intervention because it doesn’t know where and
how a conflict occurs. Conversely, during the process of
operation-based merging, when two conflicting operations
meet, the merging process is able to know a conflict
occurs and how it occurs in terms of the information in
both operations. As a result, the merging process can
provide plenty of help for human intervention.
For example, in Fig 2, User 1 and User 2 are trying to list
all conferences they are interested. User 1 thinks ACM
CSCW and IEEE ICDCS are a bit tougher for them at the
current stage, so he deletes both items in his working
copy. But User 2 adds a new item ACM GROUP between
ACM CSCW and IEEE ICDCS in his working copy. When
User 1’s change is merged into User 2’s working copy at
User 2’s site, as shown in Fig 3a, if using state-based
merging, the system can provide no help for User 2 about
the conflict but simply put two conflicting versions
together. It’s up to User 2 to decide how to manually
merge these two versions (he may consult with User 1).
2
But if using operation-based merging, as shown in Fig 3b, INTERNAL IMPLEMENTATION
the system knows exactly where and how the conflict 1. Communication between the repository and a
occurs, so it can provide adequate information for User 2 working site
to solve the conflict. In a state-based revision control system, the copy in the
repository has to be transferred to a working site in order
to compute the difference between the repository copy and
the working copy and generate an edit script. However,
...... ......
D e le te bo th lin e s ...... transferring a large document through a slow network,
• ACM CS CW such as the Internet, or through a network whose
• IEEE ICD CS bandwidth is very rare, such as mobile is really not
U ser 1
...... desirable. Moreover, transferring a sensitive document
over the network is not secure either. In contrast, an
U ser 2 I n s e rt a n e w lin e be twe e n th e lin e s operation-based revision control system does not require
transferring a repository copy to a working site because
actually performed operations instead of artificial
...... operations (i.e., an edit script) are required by the merging
• ACM CS CW process of an operation-based revision control system and
• ACM G RO UP those actually performed operations are already at that
• IEEE ICD CS working site.
...... 2. Differentiation mechanism
A state-based revision control system requires some sort
F ig 2 A delete-ins ert c onflic t of text differentiation tool, such as diff [8] to compute the
difference between two files in order to generate an edit
script. If the two files are very large, or very different (i.e.,
the edit script is very large), it could take a long time to
...... generate the edit script [10]. An operation-based revision
> > > > > > > U ser 2 's v e rs io n control system, however, does not have this burden
• ACM CS CW because it does not require the edit script at all.
• ACM G RO UP SMOOTH SWITCH BETWEEN ASYNCHRONOUS AND
• IEEE ICD CS SYNCHRONOUS COLLABORATION MODES
< < < < < < < U ser 1 's v e rs io n Pure asynchronous or synchronous collaboration mode is
...... not flexible enough for the real world. During the
development of a software project, both asynchronous and
F ig 3a Conflic t res olution in s tate-bas ed m erging synchronous collaboration modes could be required to
meet the real needs.
You have ins erted Asynchronous collaboration mode is particularly suitable
"• ACM G RO UP " ...... for the following situations:
No ......
into a deletion area • Developers are distributed geographically over the
"• ACM ... ICD CS ", world and the network connection is slow and
keep your ins ertion unreliable;
or not?
• Developers are working on different files or different
modules in a file.
Yes
Synchronous collaboration mode is particularly suitable
for the following situations:
...... • A convergent version of the project is urgently
• ACM G RO UP needed. Synchronous collaboration mode can
...... speedup the converging process;
• Developers are working on the same module in the
same file where conflicts could frequently occur;
F ig 3b Conflic t res olution in operation-bas ed m erging • Real-time communication is required among
developers. For instance, developers are
collaboratively revising some parts of the same

3
 document by means of discussion, or developers are
collaboratively debugging a program.
Above situations could happen at any stage of the
development of a software project. Therefore it would be
very helpful if collaboration can be smoothly switched
between asynchronous and synchronous modes at any
time. A state-based revision control system can support
any kind of single-user text editors, such as vi and emacs
because it is only interested with the final state of a
document instead how that document is developed from
its initial state to the final state. This is a major common
merit of all state-based revision control systems. However,
single-user editors make synchronous collaborative
editing impossible. Therefore a state-based revision
control system cannot be switched to synchronous
collaboration mode. Life would be much easier if we can
extend the technique obtained in the domain of
synchronous collaboration to the domain of asynchronous
collaboration to achieve an operation-based revision
control system that can support smooth switch between
asynchronous and synchronous collaboration modes.
An operation-based revision control system would work
as follows. In asynchronous collaboration mode,
operations are accumulated at working sites when editing.
These operations will be propagated to the repository
when the working copy needs to be merged into the
repository copy and propagated to another working site
(via the repository) when the working copy needs to be
merged into another working copy. If switched to
synchronous collaboration mode, instead of being
accumulated, operations will be propagated to all remote
sites right after the execution at the local site.
ISSUES IN OPERATION-BASED REVISION CONTROL
SYSTEMS
Operation-based revision control systems are not perfect.
There are some issues that do not exist in state-based
revision control systems must be addressed and solved in
operation-based revision control systems.
1. Operation-logged editors
Unlike state-based revision control systems in which any
kind of editors can be used, operation-based revision
control systems require special designed editors that can
catch and save edit operations. We refer to them as
operation-logged editors. To support smooth switch to
synchronous collaboration mode, these operation-logged
editors should further be collaborative. There is no free
lunch at all. It would be meaningful if what has been
gained is far beyond what has been lost. For example, if
you want to use JFC package, you have to use Java 2
instead of Java 1. Similarly, if you want to use operation-
based revision control systems, you have to use operation-
logged editors. On the other hand, to eliminate the burden
that users have to switch from their preferred editors to
new designed operation-logged editors in order to use
operation-based revision control systems, it is better not to
invent new editors but make existing editors operation-
logged or even collaborative, just as DistEdit [5] did to
make vi and emacs collaborative.
2. Number of operations
Unlike state-based revision control systems that generate
an edit script in terms of the initial and final document
states, operation-based revision control systems need to
keep all actually performed edit operations. With
operations continuously accumulated at a working site, the
number of operations could increase dramatically. Large
number of operations requires more disk space to store at
the working site and the repository, more time to
propagate between working sites and the repository, and
more time for these operations to be redone at the
repository and other working sites. When the number of
operations becomes too large to be manageable,
operation-based revision control systems could become
unacceptable. Therefore the number of operations and
even the size of each operation should be reduced to a
reasonable extent.
3. Merging process
As shown in Fig 4, suppose there is a document doc in the
repository. Site 1 and Site 2 both check out their working
copies from the repository and start modifying their own
copies independently. Site 1 finally ends up with doc1
after the execution of all operations in OB1 while Site 2
finally ends up with doc 2 after the execution of all
operations in OB2 .
doc Repos itory
c hec kout c hec kout
W orking s ites
doc doc
O B1 O B2
doc 1
doc 2
S ite 1 S ite 2
F ig 4 M erging in a revis ion c ontrol s ys tem
To merge changes from doc to doc1 into doc 2 at site 2, a
state-based revision control system normally compares the
difference among doc, doc1 , and doc 2 to generate an edit
script by the execution of which changes from doc to doc1
will be merged into doc 2 . This kind of merging is
supported by diff3 [4] in CVS. However, in an operation-
based revision control system, simply executing OB1 at
site 2 would not bring changes from doc to doc1 into
doc 2 . In [1], merging is performed by using selective redo
4
to repeat all operations in OB1 at site 2. However redo
could be conflict-prone because creating operations
equivalent to those in OB1 in the current state cannot
always be successful. Therefore, the merging process
should be well studied to maintain correctness and
effectiveness in operation-based revision control systems.
FUTURE WORK AND SUMMARY
Major issues in operation-based revision control systems
must be solved to make these systems feasible and usable.
We are trying to work out some strategies to reduce the
number of operations and the size of each operation and
manage the operation-based merging process correctly
and effectively. The representation of delta and
management of multiple versions in the repository should
also be well studied. We are concurrently use REDUCE
(REal-time Distributed Unconstrained Collaborative
Editing) system as the operation-logged editor for testing
our results. In the future, we plan to make some popular
editors, such as vi and emacs, operation-logged and even
collaborative.
In this paper, we have presented some major drawbacks in
state-based revision control systems and explained why
operation-based revision control systems can overcome
these drawbacks. We further argue that operation-based
revision control systems can ease the smooth switch
between asynchronous and synchronous collaboration
modes. Finally issues in operation-based revision control
systems have been raised and we are working on these
issues to make operation-based revision control systems
feasible and usable.
REFERENCES
1. Thomas Berlage and Andreas Genau, “A Framework
for shared applications with a replicated
architecuture,” In Proceedings of ACM Symposium
on User Interface Software and Technology, 1993.
2. Abdelmajid Bouazza and Pascal Molli: “Unifying
coupled and uncoupled collaborative work in virtual
teams,” Workshop on Collaborative Editing, ACM
Conference on Computer Supported Cooperative
Work, 2000.
3. Per Cederqvist et al: “Version Management with
CVS,” Manual for CVS.
4. Diff3 source code for CVS project,
http://oasis2.openave.net/pub/88/6/diff.diff3.c.html
5. Michael J. Knister and Atul Prakash: “DistEdit: a
distributed toolkit for supporting multiple group
editors,” In Proceedings of the conference on
Computer-supported cooperative work, 1990.
6. Ernst Lippe and Norbert van Oosterom: “Operation-
based merging,” In Proceedings of the Fifth ACM
SIGSOFT Symposium on Software development
environments, 1992.
7. Boris Magnusson et al: “Fine-grained revision control
for collaborative software development,” In
Proceedings of the first ACM symposium on
Foundations of software engineering, 1993.
8. W. Miller and E. W. Myers: “A file comparison
program,” Software - Practice and Experience, 15(1):
1025-1040, 1985.
9. J. P. Munson and P. Dewan: “A Flexible Object
Merging Framework,” In Proceedings of the
conference on Computer-supported cooperative
work, 1994.
10. E. Myers: “An O(ND) difference algorithm and its
variations,” Algorithmica, 1(2): 251-266, 1986.
11. SourceForge - Breaking Down the Barriers to Open
Source Development, http://sourceforge.net.
12. C. Sun et al: “Achieving convergence, causality-
preservation, and intention-preservation in real-time
cooperative editing systems, ACM Transaction on
Computer Human Interaction, 5(1): 63-108, 1998.
13. C. Sun and D. Chen: “A Multi-version Approach to
Conflict Resolution in Distributed Groupware
Systems,” In Proceedings of the 20th IEEE
International Conference on Distributed Computing
Systems, 2000.
14. C. Sun and C. A. Ellis: “Operational transformation
in real-time group editors: issues, algorithms, and
achievements,” In Proceedings of ACM Conference
on Computer Supported Cooperative Work, pp.59-68,
1998.
15. Walter F. Ticky: “RCS – a system for version
control,” Software Practice and Experience, 15(7):
637-654, July 1985.
16. Visual SourceSafe, http:// msdn.microsoft.com/ssafe/.