DEALING

WITH CONFLICTING MODIFICATIONS IN A WIKI

Stephan Lukosch and Andrea Leisen

Department of Mathematics and Computer Science, FernUniversit

at in Hagen

Universit

atsstraße 1, 58084 Hagen, Germany

Keywords:

Wiki, versioning, page comparison, page merging.

Abstract:

Collaborative web-based applications support users when creating and sharing information. Wikis are promi-

nent examples for that kind of applications. Wikis, like e.g. Wikipedia (Wikipedia, 2007), attract loads of

users that modify its content. Normally, wikis do not employ any mechanisms to avoid parallel modiﬁcation

of the same page. As result, conﬂicting changes can occur. Most wikis record all versions of a page to allow

users to review recent changes. However, just recording all versions does not guarantee that conﬂicting mod-

iﬁcations are reﬂected in the most recent version of a page. In this paper, we identify the requirements for

efﬁciently dealing with conﬂicting modiﬁcations and present a web-based tool which allows to compare and

merge different versions of a wiki page.

1 INTRODUCTION

Web-based applications become more and more

important and are used in different kinds of

institutions and organizations. An important cat-

egory of web-based applications is represented

by web-based collaborative systems. Exam-

ples are Google Docs (http://docs.google.com),

Yahoo Groups (http://groups.yahoo.com),

YouTube (http://www.youtube.com), Google

Earth (http://earth.google.com) or Wikipedia

(http://www.wikipedia.org).

At Google Earth, users, e.g., tag the map of the

earth with points of interest or photography that is

shared among all users. Through the efforts of the

user community, the map becomes a reﬂection of

what the inhabitants of the different places on the map

consider as relevant. The same is true for YouTube.

By allowing users to tag videos, deﬁne categories for

videos, comment videos, YouTube becomes a place

for exchanging thoughts rather than just consuming.

Yahoo groups support users in creating places for

discussion and exchanging ideas and content. The ex-

change of ﬁles is one of the core ideas of Google Docs

where users can interact synchronously on a shared

document using just their web browser as client in-

frastructure.

Wikipedia is a web-based encyclopedia that is

collaboratively written by many of its readers. For

that purpose, Wikipedia uses a wiki that records all

changes to the articles and allows to review the his-

tory of an article. Since their introduction by Ward

Cunningham in March 1994 (Leuf and Cunning-

ham, 2001), wikis achieved sustained success. Wikis

are applied in many application domains and many

wiki engines have been developed since then (Wiki

Choicetree, 2007). Part of the Wiki success is based

on their total freedom, ease of access and lack of

structure (Rick et al., 2002). Wikis serve as a means

for quickly expressing ideas and share information.

The easy way to link pages (e.g., by simple framing

with characters or by using CamelCase page names)

allows the user to create a hypertext on-the-ﬂy.

All of the above examples share an important

characteristic: They activate users to create and share

information instead of only consuming information

created by professional site owners. In most of these

examples, users are able to create information con-

currently. This may lead to conﬂicting modiﬁcations

of the same information. To overcome these issues,

most wiki engines keep a history of all page versions

and allow users to review recent changes by provid-

ing a summary. However, when several users edit the

same version of a page at the same time, a conﬂict is

reported and it is up to the user to manually include

their modiﬁcations in the most recent version. With-

out tool support, this can be tedious and users often

omit the merge process. As result not all modiﬁca-

Lukosch S. and Leisen A. (2008).

DEALING WITH CONFLICTING MODIFICATIONS IN A WIKI.

In Proceedings of the Fourth International Conference on Web Information Systems and Technologies, pages 5-15

DOI: 10.5220/0001515600050015

 SciTePress

tions ﬁnd their way in the most current version of a

wiki page.

In this paper, we describe how we addressed the

above issues by extending the standard versioning

concept and developing a web-based tool for compar-

ing and merging different wiki pages. For testing and

evaluating our approach, we extended the CURE wiki

engine (Haake et al., 2004b). However, our concepts

can easily be transferred to other wiki engines. In the

following, we ﬁrst analyze the requirements for a ex-

tended versioning concept and a web-based tool that

allows to compare and merge different pages. Then,

we describe the essential concepts and features of the

CURE system, before we present our approach. Fi-

nally, we compare our results with the current state of

the art, report on ﬁrst experiences, and conclude our

paper with an outlook on future work directions.

2 REQUIREMENTS ANALYSIS

In this section, we will determine the requirements for

versioning wiki pages and a tool that allows to com-

pare and merge different versions. For that purpose,

we will describe a typical use case in which students

have to collaboratively write a paper about Rembrandt

using a wiki engine that keeps track of different page

versions.

Anja has to write a paper about Rembrandt. The

teacher Mr. Miller has already created a wiki page

which all students can access. He also has prepared

the structure of the paper as scaffolding in a ﬁrst ver-

sion V1. Anja starts writing the text in the afternoon

and saves her version V2. While reading the text she

detects a mistake and starts editing the page. When

she has ﬁnished her changes, she forgets to save the

page and leaves the edit view opened.

Next day, Anja is not in school. Mr. Miller asks

Beate and Carla to help Anja with the paper. Beate

and Carla divide the work. While Beate checks and

corrects the part about Rembrandt’s life, Carla ex-

tends the part about Rembrandt’s work. During writ-

ing, Beate notices that she also can add content to the

other parts of the paper and extends them. When she

ﬁnishes, she saves the page as version V3.

Carla also knows much about Rembrandt and ex-

tends ﬁrst parts of the paper starting from version V2.

When she saves her work, the wiki reports a conﬂict

as Beate has already modiﬁed the version V2 and cre-

ated a new version V3. Because she has a date, she

ignores the message and leaves her computer. Now,

Anja as well as Carla have modiﬁed version V2 and

none of them has integrated the changes in the most

recent version version V3. When their computer or

just their web browser would crash now, their changes

would get lost. Especially when schedules are tight,

loosing intermediate results can make it difﬁcult to

meet deadlines. Therefore, the linear versioning con-

cept of wiki engines has to be extended and the fol-

lowing requirement has to be met:

R1: Store all page versions in a version tree and make

users aware of parallel versions.

When keeping track of all versions, no interme-

diate results will get lost and the history of a page is

completely available. However, when working with

text documents merging is time-consuming and difﬁ-

cult. There exist different approaches. Users could

copy and paste the differences between different ver-

sions. Another approach could be to use an external

merge tool. In our opinion, users should not have to

switch their work context. Instead users should be

able to resolve conﬂicts in the same application in

which the conﬂicts were created. This leads to the

following requirement:

R2: Offer a web-based tool and user interface for

comparing and merging different versions of a wiki

page.

If there are a lot of differences between two page

versions, maintaining the readability of the compared

versions becomes difﬁcult. But for merging differ-

ent versions, readability and thus a semantic under-

standing is crucial. The readability can be improved

when users can decide to suppress differences which

are rather unimportant for a semantic understanding,

e.g. added empty lines or added white spaces. There-

fore, the following requirement has to be fulﬁlled.

R3: Allow users to deﬁne options for the compari-

son.

When merging different text versions, one often

notices typos or comparable small mistakes which re-

quire correction. To make such small corrections, it

is necessary that the merged version can be edited on-

the-ﬂy. Otherwise, the merged version would have to

be stored ﬁrst and changed afterwards which would

slow down the merge process. This leads to the fol-

lowing requirement:

R4: Allow users to edit the text of a page while merg-

ing two pages.

Continuing in our scenario, Anja continues work-

ing on the paper about Rembrandt. Since she was

not in school, she does not know that Mr. Miller has

involved Beate and Carla in the writing process and

Anja saves her changes to version V2. Considering

WEBIST 2008 - International Conference on Web Information Systems and Technologies

R1, Fig. 4 displays the resulting version tree. Starting

from version V1, Anja has created version V2. V2 has

been changed by Anja, Beate, and Carla. Beate has

created version V3. When Carla stored her changes,

she created version V4. Finally, Anja now stored her

changes and the wiki created version V6. Now, three

different versions of the same page have to be merged

to keep all changes. Obviously, this is much more

complicated than merging two different versions. As

multiple conﬂicts can be serialized in conﬂicts of two

different versions, e.g. V3 and V4 and the result of

this merge with V6, the following requirement has to

be met:

Figure 1: Version tree.

R5: Support users to solve multiple conﬂicts by seri-

alizing multiple conﬂicts.

3 CURE IN A NUTSHELL

In this section, we introduce the web-based collab-

orative system CURE (Haake et al., 2003). CURE

is used for collaborative work and learning. Typical

collaborative learning scenarios are collaborative ex-

ercises, tutor-guided groups with collaborative exer-

cises, collaborative exam preparation (Lukosch and

Sch

ummer, 2006), virtual seminars, and virtual labs

(Sch

ummer et al., 2005). When considering collabo-

rative work typical use cases include group formation,

group communication, document sharing, collabora-

tive writing, collaborative task management etc.

From a technical perspective, CURE was built by

composing patterns for computer-mediated interac-

tion. For space reasons, we will not go into details of

the implementation here, but instead reference to the

patterns

that were used to create the system and show

how they appear in the functional context of user in-

teraction.

Pattern names are set in SMALL CAPS and can be found

in (Sch

ummer and Lukosch, 2007a) if no other reference is

provided.

Users can structure their interaction in GROUPS

that inhabit virtual ROOMS. Room metaphors (Green-

berg and Roseman, 2003; Pﬁster et al., 1998) have

been widely used to structure collaboration. Figure

2 shows the abstractions that are offered by CURE.

Users enter the web-based collaborative environment

via an entry room that is called Hall. Rooms can con-

tain further subrooms, content in the form of so called

pages, communication channels (e.g. an EMBEDDED

CHAT or a FORUM) and users.

Figure 2: CURE abstractions.

When users enter a room, they can participate in

collaborative activities and access the room’s com-

munication channels. They can also view the pages

that are contained in the room. Users possessing suit-

able access rights, which are represented as virtual

KEYS (Sch

ummer and Fernand

ez, 2006), can freely

edit the content of pages (Haake et al., 2004a), with

the changes being visible to all members in the room

after uploading. Earlier versions of a page remain ac-

cessible to allow tracing of recent changes. Pages may

either be directly edited using a simple Wiki-like syn-

tax (Leuf and Cunningham, 2001), or they may con-

tain binary documents, e.g. JPEG images, Microsoft

Word documents etc. In particular, the syntax sup-

ports links to other pages, other rooms, external URLs

or mail addresses. The server stores all artifacts to

support collaborative access. Thus, when users leave

the room, the content stays available, allowing them

to come back later and continue their work on the

room’s pages.

Figure 3 shows a typical room in CURE. The

numbers in the ﬁgure refer to details explained in the

following paragraphs. A room contains documents

(¬, cf. CENTRALIZED OBJECTS) that can be edited

by those users, who have sufﬁcient edit rights .

CURE stores all versions of a page as IMMUTABLE

VERSIONS. Users can browse different versions ®

to understand their colleagues’ changes (cf. TIME-

LINE). Communication is supported by two room-

based communication channels, i.e. a FORUM ¯ and

an EMBEDDED CHAT °. Users can use the room-

DEALING WITH CONFLICTING MODIFICATIONS IN A WIKI

Figure 3: A room in CURE.

based e-mail to send a mail to the room. Users of the

room that have sufﬁcient communication rights will

receive this message like being a member of a MAIL-

ING LIST (Sch

ummer and Lukosch, 2007b).

By providing a plenary room, sharing and com-

munication in a whole class or organization can be

supported. By creating new rooms for sub-groups

and connecting those to the classes’ or organization’s

room, work and collaboration can be ﬂexibly struc-

tured. Starting from the plenary room users can NAV-

IGATE (Sch

ummer and Fernand

ez, 2006) to the con-

nected sub-rooms ±.

For user coordination, CURE supports various

types of awareness information:

1. Users can see in the room’s properties who else

has access to this room ².

2. Users can see in a USER LIST ³ who else is cur-

rently in the same room.

3. If the EMBEDDED CHAT ° is enabled in the

room, users can directly start chatting to each

other.

4. Users can trace who has previously edited the cur-

rent page ´ (cf. ACTIVE NEIGHBORS).

5. PERIODIC REPORTS automatically posted to all

users of a room include all changes made since

the last report was sent.

4 APPROACH

The following sections will give a detailed descrip-

tion of our approach to address the identiﬁed require-

ments (R1 – R5). To show the feasibility of our ap-

proach, we extended the web-based collaborative sys-

tem CURE that so far does not fulﬁll any of the iden-

tiﬁed requirements.

4.1 Version Tree (R1)

To keep a history of all changes, even when

users changed the same page version in parallel,

we extended the versioning concept in CURE by

implementing the pattern IMMUTABLE VERSIONS

(Sch

ummer and Lukosch, 2007a). In this pattern, ver-

sions are immutable as they cannot be changed after-

wards. Each modiﬁcation of a page is stored as new

version in a version tree even when two users mod-

WEBIST 2008 - International Conference on Web Information Systems and Technologies

iﬁed the same page version concurrently. This ap-

proach is also used to handle conﬂicting modiﬁcations

that result from nomadic interaction with the CURE

system (Lukosch et al., 2006; Lukosch, 2008).

Apart from creating a new parallel page version,

CURE also creates a so-called merge-page which ref-

erences the parallel versions. After extending the ver-

sion tree, CURE asks the users to resolve the con-

ﬂict on the merge-page. CURE thereby prevents users

from overwriting changes other users have performed.

Fig. 4 shows how the version tree of our scenario

is extended with the merge-pages which make users

aware of conﬂicting changes.

Figure 4: Version tree in CURE.

4.2 Web-based Comparison and Merge

Tool (R2)

4.2.1 Selecting Different Page Versions

For comparing and merging, users ﬁrst have to select

two different page versions. We integrated a button,

which allows users to directly compare the currently

viewed version of a page with its direct predecessor.

Apart from that direct access, users can also freely se-

lect two different page versions from the version tree

of a page in CURE. Fig. 5 shows how CURE displays

the version tree. Users can select two pages for com-

parison ¬ or merging  by selecting the correspond-

ing radio buttons ®.

Since the user must select exactly two versions,

two groups of radio buttons were integrated in the

page showing version tree (see Fig. 5). In each group,

only one version can be selected. All existing ver-

sions of a page are available in each group. The se-

lection takes place on the client side in the browser.

The number of available radio buttons in each group

Figure 5: Selecting pages for comparison or merging in

CURE.

are adapted to the reasonable ones, once users make

their choice. This ensures that users can only select

two different versions for comparison or merging.

Additionally, users can alter their selection and

can compare or merge different versions, while us-

ing the comparison and merging tool. This is possible

by using drop-down menus on top the comparison or

merging tool (see Version selection area in Fig. 6, 7,

and 8).

4.2.2 Comparing Different Page Versions

For the comparison of two pages, we use a standard

comparison algorithm (Myers, 1986). This algorithm

ﬁrst identiﬁes the different lines and then the differ-

ences in the different lines. The output of the al-

gorithm is an edit script, i.e. a list of

delete

and

insert

operations, which is used to mark the differ-

ences. The differences are presented on the compari-

son page which is divided into the three areas version

selection, side-by-side view, and toolbar (see Fig. 6).

The version selection area provides two possibili-

ties to choose the versions for comparison. Either the

user can skip to the previous/next version of the page

by using buttons or by selecting a dedicated version

out of a list. This list offers only reasonable versions,

i.e. those which are older or newer than the displayed

versions.

The side-by-side view area shows both versions in

two columns beside each other (Yang, 1991). Similar

lines are shown at the same height in order to com-

pare them easily. The differences between two page

versions are marked by using different font and color

attributes. In addition to the different layout, differ-

ences are indicated by suitable symbols (+, -, ≡) in an

additional column per version. This approach is also

used in Wikipedia (Wikipedia, 2007).

The toolbar area offers two buttons for either in-

voking the merge page or canceling the comparison

DEALING WITH CONFLICTING MODIFICATIONS IN A WIKI

Figure 6: Comparing two pages in CURE.

which means to invoke the version selection page.

Additionally, users can choose between three differ-

ent options which inﬂuence the comparison (see Sec-

tion 4.3).

4.2.3 Merging Different Page Versions

Apart from the comparison tool, we integrated two

different possibilities to merge different page versions

in CURE. The ﬁrst possibility uses the side-by-side

view (see Fig. 7). The side-by-side view is preferred

by, e.g., programmers when comparing source code

(DiffDoc, 2007). The second possibility uses only

the merge view and adds a result view (see Fig. 8).

Thereby, it offers a more integrated view of the differ-

ent versions. Experiences have shown that the merge

view is preferred for the comparison of literary texts.

Since the type of presentation depends on the text type

which is compared as well as on the user’s personal

preferences, we implemented both possibilities.

Both user interface variants support the user while

merging. The vertical scrollbars of the side-by-side

and merge view in Fig. 7 as well as the merge and re-

sult view in Fig. 8 are synchronized. Thereby, users

can always see the corresponding parts of the com-

pared and merged versions. In the following, we will

describe the merge view, result view, and the toolbar

in more detail.

The merge view presents both versions in a single

integrated view. In contrast to the side-by-side view,

identical text-parts are presented only once.

For each difference, users have to decide in the

merge view which text should be transferred into the

merged version. An automated decision is not pos-

sible, because the two versions are not necessarily

based on the same version. The differences which

have to be solved manually are called conﬂicts. There

are two different types of conﬂicts:

• Unary conﬂict: Text-parts that appear only in one

of the two versions, i.e. difference in one text e.g.

inserted or deleted words or lines.

• Binary conﬂict: Text-parts that exist in both ver-

sions at the same position, i.e. concurrent differ-

ence at the same position in the text.

In case of a unary conﬂict, users have to decide

whether this text-part should be transferred into the

merged version or not. Binary conﬂicts are positioned

directly one after the other. Users have to decide,

which of the two possible text-parts should be trans-

ferred. It is not possible to transfer both text-parts.

Users can resolve such conﬂicts by directly click-

ing on the conﬂict. With each click on a conﬂict, the

conﬂict changes its state. A conﬂict can be in three

different states:

1. Initial: Status at the beginning of merge process.

2. Active: Text is part of the merged version.

3. Inactive: Text is not part of the merged version.

When the conﬂict state changes, the layout of the

conﬂict is also changed. Table 1 shows the layout

of the different conﬂict states. When all conﬂicts are

solved, i.e. all conﬂicts have the status active or inac-

tive, the merge process is ﬁnished and users can save

the merged page as new version.

The result view (see Fig. 8) shows users a preview

of the merged page. In the beginning of the merge

process, only the identical text-parts are shown. With

each solved conﬂict in the merge view the conﬂict free

WEBIST 2008 - International Conference on Web Information Systems and Technologies

Figure 7: Merging two pages with the side-by-side view in CURE.

Table 1: Layout of the different conﬂict states.

Conﬂict

state

Unary

conﬂict V1

Unary

conﬂict V2

Binary

conﬂict

Initial black

on light

yellow

black on

light green

Text V1.

Text V2.

Active red and

fat on

light

yellow

red and

fat on

light

green

Text V1.

Text V2.

Inactive black and

crossed

out on

light

yellow

black and

crossed

out on

light

green

Text V1.

Text V2.

text-part is added to the result view as well. The text-

parts are marked with the same background-color as

in the merge view such that users can recognize the

originating version.

For awareness purposes, the toolbar area offers in-

formation about the number of solved and unsolved

conﬂicts. Again, users can deﬁne the options for com-

paring to page versions (see Section 4.3). Addition-

ally, the toolbar offers a variety of functions to support

users when merging two pages (see Fig. 7 from left

to right):

• Transfer remaining differences from the right ver-

sion: Often, users want to accept most of the con-

ﬂicts from one page version. This function allows

to accept all not yet decided conﬂicts from one

version.

• Transfer remaining differences from the left ver-

sion: The same function as the previous one, just

vice versa.

• Accept all active and decided conﬂicts: All active

conﬂicts are accepted and displayed as identical

text-parts.

• Cancel all modiﬁcations: All modiﬁcations are re-

set and the the user can start the merging process

again.

• Preview the merged page: This function allows

the user to preview the merge page.

• Back to the merge view: All unsolved and all

crossed out text-parts are displayed again.

• Save the intermediate merge result: Users can

save the intermediate result of their merge pro-

cess. This function does not result in a new page

version.

• Load the last intermediate merge result: Users

can load the last intermediate result.

• Save merged page: When all conﬂicts are re-

solved, the save button is enabled and users can

save the merged page as new version.

• Return to the version selection: By using this

function, users can return to the page that shows

the version tree of a page (see Fig. 5).

DEALING WITH CONFLICTING MODIFICATIONS IN A WIKI

Figure 8: Merging two pages with the result view in CURE.

4.3 Comparison and Merge Options

(R3)

Users can choose between three different options

which inﬂuence the comparison or the merge process

(see, e.g., lower right corner of Fig. 6):

• Ignore empty lines.

• Ignore whitespaces.

• Ignore block-format.

Empty lines between text-sections and whitespaces

are not relevant for the content of a text. With the op-

tions ignore empty lines and ignore whitespaces users

can change the treatment of empty lines and whites-

paces as differences. When only textual differences

are important, these options help to improve the clear-

ness of a comparison.

Block-formats are formatting instructions in the

wiki syntax which mark beginning and end of a char-

acter string, e.g. in CURE

˜˜text˜˜

is rendered as

italic. When users choose to ignore block-formats,

only the formatting instructions are presented as dif-

ferences and not the formatted text.

4.4 Editing Merged Text (R4)

When merging two pages, users often notice text-

parts or words which they would like to correct im-

mediately, e.g. typos, punctuation marks etc. For that

purpose, we integrated an editor which allows users

to choose the text they want to edit by simply clicking

on it. Once the text is chosen, a small edit window ap-

pears and allows the users to make spontaneous cor-

rections (see merge view in Fig. 7).

To encourage users to integrate the modiﬁcations

of other users, only text parts without conﬂicts can

be edited. Thus, users ﬁrst have to resolve the con-

ﬂicts before editing can take place. Once all conﬂicts

are resolved, it is possible to edit the entire text. But

this is not reasonable. In case of larger modiﬁcations,

users should save the merged version ﬁrst and edit the

resulting new version afterwards.

4.5 Solving Multiple Conﬂicts (R5)

When multiple users edit a version of a page simulta-

neously, conﬂicting pages version result. By fulﬁlling

R1, no page version gets lost. However, this also re-

sults in more than two parallel versions. In case of

our example (cf. Section 2), Anja, Beate, and Carla

edit the same page which results in three parallel ver-

sions. When Carla saves the modiﬁed page, CURE

now detects the conﬂict and shows the comparing and

merging tool as shown in Fig. 7. However, when Anja

saves her page version, three different versions have

to be merged.

Adding an additional column in the side-by-side

view (Fig. 7) or integrating another text in the merge

WEBIST 2008 - International Conference on Web Information Systems and Technologies

Figure 9: Merge hierarchy in CURE.

view (Fig. 8) is not feasible, as it would be difﬁcult

for users to keep an overview. This becomes even

more obvious, when considering 4, 5, 6 or even more

parallel versions.

In order to simplify the merge process of three or

even more pages, we split up the merge process in

serially merging two versions. To support the user

in serializing the multiple conﬂicts, CURE shows the

merging hierarchy in form of a table (see Fig. 9).

The user can start the merging process by clicking on

the ”merge” button and merge the two corresponding

page versions. If further versions need to be merged,

an updated merging hierarchy is shown again after the

user has merged the selected pages. Thereby, the con-

ﬂicting versions are serially merged and the modiﬁca-

tions of all users are taken into account.

5 RELATED WORK

There are several available comparing- and merging

tools that run on different platforms and are suit-

able for different ﬁle types like text ﬁles, binary ﬁles

and HTML or XML ﬁles. A large part of these

tools is based on the GNU diffutils (Diffutils - GNU

Project, 2007) and offers a graphical user interface.

Some of these tools also support editing and merg-

ing of ﬁles. In this section, we will analyze some

of these tools concerning their functionality. The fol-

lowing list contains some of those tools in alphabetic

order: CharDiff (CharDiff, 2007), DiffDoc (Diff-

Doc, 2007), DiffDog (DiffDog, 2007), CSDiff (CS-

Diff, 2007), ExamDiff Pro (ExamDiff Pro, 2007),

Guiffy (Guiffy, 2007), KDiff3 (KDiff, 2007), Meld

(Meld, 2007), RCS (Tichy, 1985), TkDiff (TkDiff,

2007), Unix diff (Hunt and McIlroy, 1976), Wikipedia

(Wikipedia, 2007), and WinMerge (WinMerge, 2007).

Most of these tools work line-based. They try

to ﬁnd common lines and lines that have been in-

serted or deleted by searching the longest common

subsequence between the texts. From the sighted

tools Wikipedia, CharDiff, DiffDoc, WinMerge and

Guiffy are analyzed in depth, since they have exem-

plary character for the different types of comparing

and merging tools.

Wikipedia (Wikipedia, 2007) is a wiki that allows

visitors to add, remove, edit and change content, typ-

ically without the need for registration. If a wiki page

is changed, the whole page is stored as new version.

In case of a conﬂict, the new version is not stored and

users have to integrate their changes in the most recent

version. Otherwise, their changes are lost (violating

R1). Within Wikipedia users can compare two ver-

sions of a page. The changes between two revisions

of a page are displayed side-by-side.

However, Wikipedia does not support merging of

two different versions (violating R2).

CharDiff 1.2a (CharDiff, 2007) is a shareware

program that detects and presents differences with

character precision and overlays ﬁles for an integrated

display. CharDiff uses standard web browsers for the

presentation of the differences. After selecting two

ﬁles for comparison, the result of the comparison im-

mediately is shown in a single integrated view in the

web browser. If the mouse is positioned on the dif-

ference, the difference waggles in the integrated view.

This effect draws the user’s attention to the selected

difference. A support to merge two ﬁles does not ex-

ist (violating R2)..

Diff Doc 3.50 (DiffDoc, 2007) is a commercial

tool for comparing ﬁles, e.g. PDF, Word, Excel, RTF,

text or HTML ﬁles. The two compared ﬁles are rep-

resented in a side-by-side view in the upper part of

the user interface in which users can also edit the

viewed ﬁles. The two compared ﬁles can be loaded

by opening existing ﬁles, by copy and paste of text

parts, or by creating new text. In the lower area of the

user interface, the differences are either presented in

a side-by-side-view or in an integrated view. For the

comparison, three options are available: ignore up-

per and lower case, ignore white spaces, and ignore

empty lines. Again, merging is not supported (violat-

ing R2).

WinMerge 2.6 (WinMerge, 2007) is an open

source tool for comparing and merging of text ﬁles.

The two compared texts are shown in a side-by-side

view, where identical lines are ordered on the same

height and differences within the lines are marked in

DEALING WITH CONFLICTING MODIFICATIONS IN A WIKI

another color. However, WinMerge does not support

to resolve multiple conﬂicts (violating R5).

Guiffy 7.4 (Guiffy, 2007) is a Java shareware pro-

gram for comparing and merging of ﬁles. Thus, it can

be used with different operating systems. Guiffy sup-

ports 3-way merging with its SureMerge function and

offers an intuitive user interface. But Guiffy is not a

web-based tool and does not offer support for solving

multiple conﬂicts (R5).

Table 2: Comparison of tools.

Requirement

Wikipedia

CharDiff

Diff Doc 3.50

WinMerge 2.6

Guiffy 7.4

R1 - - - - -

R2 - - - ◦ ◦

R3 ◦ + + + +

R4 - - ◦ + +

R5 - - - - -

+: Requirement is fulﬁlled

◦ Requirement is partially fulﬁlled

- : Requirement is not fulﬁlled

Table 2 shows the results of our analysis in ac-

cordance with our requirements (R1 – R5). To sum-

marize, none of the above tools fulﬁlls all of the re-

quirements. Especially, none supports version trees

or offers web-based merging support.

6 FIRST EXPERIENCES

We split up the evaluation of our support for com-

paring and merging different wiki page versions in

three phases. In the ﬁrst phase, we have conducted

functional tests. These functional tests concentrated

on validating the comparing and merging possibilities

and checking if our requirements are met. These tests

showed that all identiﬁed requirements R1 – R5 are

fulﬁlled.

In a second phase, we setup a test environment

in our group and let several groups test the system.

Feedback from these users with different background,

i.e. expert as well as lay users from different depart-

ments at our university, indicates that our tools for

comparing and merging different wiki pages improve

the usability of the system and are highly intuitive for

dealing with conﬂicting modiﬁcations in wikis. Fur-

thermore, users have reported that the tools signiﬁ-

cantly simplify to review recent changes and to re-

solve conﬂicts.

CURE is regularly used by our group to conduct

seminars as well as lab courses with a blended CSCL

approach (Haake et al., 2005). In the ﬁnal evalua-

tion phase, we plan to use CURE together with our

tools for comparing and merging in seminars and lab

courses which follow the same blended CSCL ap-

proach. Based on the gathered interaction data, we

plan to evaluate how the tools affect the interaction

among the users.

7 CONCLUSIONS

Nowadays, web-based applications become more and

more important. Especially, collaborative web-based

applications activate users to create and share infor-

mation instead of only consuming it. However, when

collaboratively accessing and modifying shared infor-

mation, parallel modiﬁcations can take place. Most

wikis record all versions of a page to allow users to

review recent changes, but also to ensure that no mod-

iﬁcations get lost.

In this paper, we identiﬁed ﬁve requirements for

supporting users when working with different ver-

sions in a wiki. We showed how to fulﬁll these re-

quirements by extending the linear version concept of

wikis and integrating a web-based tool for comparing

and merging wiki pages in CURE. The overall con-

cepts, like the version tree, the side-by-side view, the

result view, the different layouts for highlighting con-

ﬂicts and differences, and the process for solving mul-

tiple conﬂicts, can easily be transferred to other wiki

engines as well.

Up to now, there is no wiki that supports parallel

versions and offers a tool for comparing and merging

different wiki pages. Thus, our approach which has

been integrated in CURE presents a signiﬁcant step

forward. In future, we want to further evaluate the

effects of the comparing and merging tools on the us-

age of CURE. Additionally, we want investigate in

how far the merging process can be even more sup-

ported by offering more user-deﬁned options for the

comparison, by considering the structure of the text,

or by enabling automatic merging.

REFERENCES

CharDiff (2007). http://calendar.google.com.

CSDiff (2007). http://www.componentsoftware.com/pro

ducts/CSDiff/index.htm.

DiffDoc (2007). http://www.softinterface.com/Compare-

File-Programs/Compare-File-Programs.HTM.

WEBIST 2008 - International Conference on Web Information Systems and Technologies

DiffDog (2007). http://www.altova.com/products/diffdog/

diff merge tool.html.

Diffutils - GNU Project (2007). http://

www.gnu.org/software/diffutils/.

ExamDiff Pro (2007). http://www.prestosoft.com/ps.asp?

page=edp examdiffpro.

Greenberg, S. and Roseman, M. (2003). Using a room

metaphor to ease transitions in groupware. In Acker-

mann, M., Pipek, V., and Wulf, V., editors, Sharing

Expertise: Beyond Knowledge Management, pages

203–256. MIT Press, Cambridge, MA, USA.

Guiffy (2007). http://www.guiffy.com/.

Haake, J. M., Haake, A., Sch

ummer, T., Bourimi, M.,

and Landgraf, B. (2004a). End-user controlled group

formation and access rights management in a shared

workspace system. In CSCW ’04: Proceedings of the

2004 ACM conference on Computer supported coop-

erative work, pages 554–563. ACM Press, New York,

NY, USA.

Haake, J. M., Haake, A., Sch

ummer, T., and Lukosch, S.

(2005). Collaborative learning at a distance with the

project method. Educational Technology, 45(5):21–

24.

Haake, J. M., Sch

ummer, T., Haake, A., Bourimi, M., and

Landgraf, B. (2003). Two-level tailoring support for

CSCL. In Favela, J. and Decouchant, D., editors,

Groupware: Design, Implementation, and Use, 9th

International Workshop, CRIWG 2003, LNCS 2806,

pages 74–82. Springer-Verlag Berlin Heidelberg.

Haake, J. M., Sch

ummer, T., Haake, A., Bourimi, M., and

Landgraf, B. (2004b). Supporting ﬂexible collabora-

tive distance learning in the CURE platform. In Pro-

ceedings of the Hawaii International Conference On

System Sciences (HICSS-37). IEEE Press.

Hunt, J. W. and McIlroy, M. D. (1976). An algorithm for

differential ﬁle comparison. Computing Science Tech-

nical Report 41, Bell Laboratories.

KDiff (2007).http://kdiff3.sourceforge.net/.

Leuf, B. and Cunningham, W. (2001). The WIKI way.

Addison-Wesley, Boston, MA, USA.

Lukosch, S. (2008). Seamless transition between connected

and disconnected collaborative interaction. Journal of

Universal Computer Science (JUCS), Special Issue on

’Groupware: Issues and Applications’.

Lukosch, S., Hellweg, M., and Rasel, M. (2006). CSCL,

Anywhere and Anytime. In Dimitriadis, Y. A., Zig-

urs, I., and G

omez-S

anchez, E., editors, Groupware:

Design, Implementation, and Use, 12th International

Workshop, CRIWG 2006, LNCS 4154, pages 326–

340. Springer-Verlag Berlin Heidelberg.

Lukosch, S. and Sch

ummer, T. (2006). Making exam prepa-

ration an enjoyable experience. International Jour-

nal of Interactive Technology and Smart Education,

Special Issue on ’Computer Game-based Learning’,

3(4):259–274.

Meld (2007). http://meld.sourceforge.net/.

Myers, E. W. (1986). An O(ND) difference algorithm and

its variations. Algorithmica, 1(2):251–266.

Pﬁster, H.-R., Schuckmann, C., Beck-Wilson, J., and Wess-

ner, M. (1998). The metaphor of virtual rooms in the

cooperative learning environment CLear. In Streitz,

N., Konomi, S., and Burkhardt, H., editors, Coopera-

tive Buildings - Integrating Information, Organization

and Architecture. Proceedings of CoBuild’98, LNCS

1370, pages 107–113. Springer Heidelberg.

Rick, J., Guzdial, M., Carroll, K., Holloway-Attaway, L.,

and Walker, B. (2002). Collaborative learning at low

cost: CoWeb use in english composition. In Proceed-

ings of CSCL 2002, Boulder, Colorado, USA.

Sch

ummer, T. and Fernand

ez, A. (2006). Patterns for virtual

places. pages 35–74. UVK Universit

atsverlag Kon-

stanz GmbH.

Sch

ummer, T. and Lukosch, S. (2007a). Patterns for

Computer-Mediated Interaction. John Wiley & Sons,

Ltd.

Sch

ummer, T. and Lukosch, S. (2007b). READ.ME – Talk-

ing about computer-mediated communication. pages

317–342. UVK Universit

atsverlag Konstanz GmbH.

Sch

ummer, T., Lukosch, S., and Haake, J. M. (2005).

Teaching distributed software development with the

project method. In Koschmann, T., Suthers, D. D.,

and Chan, T.-W., editors, Computer Supported Col-

laborative Learning 2005: The Next 10 Years!, pages

577–586. Lawrence Erlbaum Associates.

Tichy, W. F. (1985). RCS – a system for version control.

Software Practice and Experience, 15(7):637–654.

TkDiff (2007). http://sourceforge.net/projects/tkdiff/.

Wiki Choicetree (2007). http://c2.com/cgi/

wiki?WikiChoicetree.

Wikipedia (2007). Main page – wikipedia, the free ency-

clopedia. (Online; Stand 24. April 2007).

WinMerge (2007). http://winmerge.org/2.6/manual/.

Yang, W. (1991). Identifying syntactic differences between

two programs. Software-Practice and Experience,

21(7):739–755.

DEALING WITH CONFLICTING MODIFICATIONS IN A WIKI