Structural and Cognitive Problems in providing Version Control for Hypertext (Kasper Osterbye)

[ACM Link]
This paper was all about the mechanics of making versions in a versioned hypertext environment (read: really messy complicated collaborative space) but it brought out a few interesting ideas. First, it talks about two different versioning creation behaviors: ’Äúexploratory’Äù and ’Äúassembly line’Äù. Exploratory versioning is like what we observe a designer doing. She makes a new version of a doc to make a few changes that are being explored, but wants to save the orig to fall back on in case the changes don’Äôt work out. Our designer CI showed a lot of diff versions of the same thing ’Äì none more current than the others ’Äì that all were explorations, but still needed to be saves. Assemble line versioning is like what we do when we write a paper: every version is a save point along a deliberate process. Each version has one successor and one predecessor (unless it is the initial version) The paper suggests that in the case of exploratory versioning, the author wants to freeze the predecessor of an exploration to fall back on ’Äì so that it can’Äôt be changed while they are out exploring. In the case of the assembly line versioning, the author wants to freeze the version that is made after the assemble operations have been completed ’Äì assuming the changes are completely done. The freezing metaphor is really only useful in a collaborative environment, but I think it could be a useful metaphor for use in a single user application. The paper also discusses the problem of cognitive overhead in versioning ’Äì that having to do a lot of work in the creation and selection parts of versioning detracts from the real work. If we were to implement some sort of query to select a version, we could be making a ’Äúhigh maintenance’Äù versioning system.

Versioning

VerSE: Towards Hypertext Versioning Styles

Haake, Hicks

This paper talks about the evolution of hypertext versioning systems towards a completely task based system.

A task based versioning system is a system in which changes to an object (e.g. text file) are grouped by task rather than the change itself. This is useful if multiple objects were changed in parallel in support of a task. This is in contrast to the object based approach where each object maintains its own versions. The object based approach has the problem ’Äì as the paper suggests ’Äì that there is a lot of cognitive overhead in version selection probably because it is difficult to find which version you want.

’ÄúThe central idea of the task based approach is to provide system support for marinating the relationships between versions of objects that have been changed in a coordinated manner’Ķto ensure that those versions can be later identified is having implemented a set of coordinated changes. In this way, unintended combinations of component versions can be ruled out a priori and version selection can be done via change information’Äù

The task is seen as the best way to provide a meaningful cue to version identification.

There are also linear change tasks and parallel change tasks. In linear tasks, there is one sequence of changes before and one after any given change. In this way, it is only necessary to keep the changes that have been made to an object (change based) and not the whole object (state based)

In a parallel change task, multiple objects are changed as part of a task. A parallel change task seems to be comprised of several linear change tasks. The parallel change task can be frozen into task ’Äì the advantage being that this becomes an atomic task and can then easily be referred to later ’Äì for example a linear change can be referred to as ’ÄúI added some info about shellfish’Äù whereas a task change can be referred to as ’Äúshellfish info was added to all these documents’Äù What the hell is the difference you ask? Well, if you have multiple documents that rely on each other or are part of a project group, you can make it easier to identify changes to the group when they are encapsulated in a change rather than have each object have a lot of changes and then have to line those up with other objects that are changed in parallel. Obviously, there are going to be linear changes to each object even in a task change, but the point is that you have to group them in a task to have effective versioning.

Design Spaces for Link and Structure Versioning

Whitehead, James Good paper on the structure of a versioning system...if we every have to build one.

Metadata Efficiency in CVFS

Gary Marsden, David E. Cairns
[Link]
A comprehensive versioning file system creates and retains a new file version for every WRITE or other modification request. The resulting history of file modifications provides a detailed view to tools and administrators seeking to investigate a suspect system state. Conventional versioning systems do not efficiently record the many prior versions that result. In particular, the versioned metadata they keep consumes almost as much space as the versioned data. This paper examines two space-efficient metadata structures for versioning file systems and describes their integration into the Comprehensive Versioning File System (CVFS). Journal-based metadata encodes each metadata version into a single journal entry; CVFS uses this structure for inodes and indirect blocks, reducing the associated space requirements by 80%. Multiversion b-trees extend the per-entry key with a timestamp and keep current and historical entries in a single tree; CVFS uses this structure for directories, reducing the associated space requirements by 99%. Experiments with CVFS verify that its current-version performance is similar to that of non-versioning file systems. Although access to historical versions is slower than conventional versioning systems, checkpointing is shown to mitigate this effect.