[Gnome-devtools] glf - versioning
- From: Mark <jamess1 wwnet com>
- To: "gnome-devtools helixcode com" <gnome-devtools helixcode com>
- Subject: [Gnome-devtools] glf - versioning
- Date: Fri, 02 Jun 2000 13:49:10 -0400
Hello,
I would like to describe in a bit of detail the versioning system that
glf will employ. I originally was intending on a strait implementation
based on [1]. However after talking to JP Rosevear on devel-apps I
realized that this is not sufficient. The versioning system described in
[1] does not at all deal with the file system. Yet there is a number of
tools that operate on the file directly and have no knowledge of glf,
one example is cvs. So I would like to extend the existing versioning
system to include file support.
Background:
The versioning system in [1] associates versions of a document with
nodes in a tree structure which is called the global version tree. Each
version is named by a unique integer. The initial version of a document
is simply an empty document, with the global versioning tree containing
a single node. As modifications are made new nodes are added to the
version tree. Each node in the tree can be the basis for any number of
versions. After a version is committed it becomes read-only.
Here is a sample editing sequence:
0 - initial document
1 [ type 'a' ]
2 [ type 'b' ]
3 [ type 's' ]
[ undo ]
4 [ type 'c' ]
5 [ type 'd' ]
And here is the corresponding versioning tree:
0
|
1
|
2
/ \
3 4
|
5
File support:
The basic extension of this model to allow for file support, is to
associate some versions of a document with those stored in files. So
initially, the file being edited would be loaded and the initial version
0 would be the state of the file upon opening. Editing can then continue
as normal. When an external tool edits the document, the base version
for the modification is the last saved version in the tree. glf would
have to monitor the file for to know when an external tool modifies it,
I'm not sure the details of this, but I do know it is possible. So the
version generated by the external tool is just another another branch in
the tree. It is up to the application to decide to merge different
versions in the tree.
Here is a sample editing sequence:
0 - initial document loaded from a file.
1 - 26 [ series of textual edits ]
... ... ...
26 [ saved to file ]
27 - 30 [ series of textual edits ]
... ... ...
31 [ cvs update ]
And here is the approximate versioning tree:
0 <- initial version of file
/|\
/| \
...
|
26 <- file saved
/ \
cvs update -> 31 |\
|
Identification:
Another related topic when talking about versioning is identification
of tools that make changes. Since one of the main ideas behind glf is to
allow multiple tools to work on the same document, you have to have and
identification system so tools can know whether or not they want to
incorporate changes and how they should do so. I'm not sure exactly how
to identify external tools, so if someone could fill me in on this I
would like to know. Identification of tools that use glf directly should
be pretty easy. I think each tool would register with glf, which would
get them an id. Each time they made changes they would use the same id.
Status:
Currently I have most the code in place for the versioning system. I
don't think the file support, or identification is needed right away,
but it should be there in future versions.
I want to get the whole source tree in cvs really soon. It is not
working, but I think the basic framework is there so other people can
check out the progress I've made, and others can hopefully contribute.
The code I have now is mainly focused on the C implementation. However I
want to structure the code so corba interface can be easily integrated
later. If anyone wants to help with this I would appreciate it a lot,
I'm still learning how to implement a corba server.
Mark
[1] Tim Wagner's Ph.D. Dissertation -
http://www.cs.berkeley.edu/~harmonia/pubs.html#[Wag97]
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]