118
support a wider range of access and update operations. Interactive editors need random ac-
cess to support navigation and to be able to retrieve smaller portions of the sequence to fill
screen buffers. Applications need to register user actions and remote updates, incrementally
adding changes to change sets representing P-sequences. Finally, support for single- or
multi-user undo means support for the incremental removal of a change from a change set.
Given a change set U, the universe, containing all changes known at an instance of an
application, and change sets V
1 , …, V
n ˝ U,we are interested in supporting the following
capabilities:
1. Add(c, U):Add a changectoU.
2. LookupChange(ID, U):find all information about a change inU.
3. FetchRange(a
1 , a
2 , V
i ):Retrieve the contents of a range(a
1 , a
2 )in some change setV
i .
4. AddChange(c, V
i ): Update a change setV
i by adding a change c.
5. DeleteChange(c, V
i ):Update a change setV
i by removing a change cfrom it.
6. CreateChangeset(c
1 , …, c
k ):Create a new change setV
i from a set of changes {c
1 , …,
c
k }.
As with VTML, we will assume that change sets are explicitly represented objects: this will
allow us to build incremental indices including only the operations in those versions, thus
speeding overall performance. This strategy allows us to keep the runtime dependent on the
number of changes in a version, rather than the total number of changes in the universe.
This is potentially a useful savings, because of the effects of user undo actions and those
made to resolve merge conflicts. These are likely to lead to the removal of some operations
from all active versions of interest to the user (and these operations are also candidates for
garbage collection).
The P-sequences defined by particular V
i represent the contents of significant versions.
These versions may be permanent records of historical states, as in a traditional versioning
system. Alternatively, they may represent the working state of an application which is man-
support a wider range of access and update operations. Interactive editors need random ac-
cess to support navigation and to be able to retrieve smaller portions of the sequence to fill
screen buffers. Applications need to register user actions and remote updates, incrementally
adding changes to change sets representing P-sequences. Finally, support for single- or
multi-user undo means support for the incremental removal of a change from a change set.
Given a change set U, the universe, containing all changes known at an instance of an
application, and change sets V
1 , …, V
n ˝ U,we are interested in supporting the following
capabilities:
1. Add(c, U):Add a changectoU.
2. LookupChange(ID, U):find all information about a change inU.
3. FetchRange(a
1 , a
2 , V
i ):Retrieve the contents of a range(a
1 , a
2 )in some change setV
i .
4. AddChange(c, V
i ): Update a change setV
i by adding a change c.
5. DeleteChange(c, V
i ):Update a change setV
i by removing a change cfrom it.
6. CreateChangeset(c
1 , …, c
k ):Create a new change setV
i from a set of changes {c
1 , …,
c
k }.
As with VTML, we will assume that change sets are explicitly represented objects: this will
allow us to build incremental indices including only the operations in those versions, thus
speeding overall performance. This strategy allows us to keep the runtime dependent on the
number of changes in a version, rather than the total number of changes in the universe.
This is potentially a useful savings, because of the effects of user undo actions and those
made to resolve merge conflicts. These are likely to lead to the removal of some operations
from all active versions of interest to the user (and these operations are also candidates for
garbage collection).
The P-sequences defined by particular V
i represent the contents of significant versions.
These versions may be permanent records of historical states, as in a traditional versioning
system. Alternatively, they may represent the working state of an application which is man-
