From: Tomas Frydrych (tomasfrydrych_at_yahoo.co.uk)
Date: Sun Dec 14 2003 - 04:21:32 EST
This is just few notes of explanations on my recent revisions and
versioning work (I am planing to commit a lengthy how-to by the end
of the week).
Conceptually revisions are like scribling with red pen onto a paper
printout. Any changes made to a document in the revisions-on mode are
recorded and can be shown in different colour for different authors.
Subsequently, they can be accepted (incorporated permanently into the
document) or rejected (erased from the document).
To avoid any misunderstanding: revision information is only recorded
in revisions-on mode which is controlled by the user; nothing
sinister happening here.
In addition to marking and accepting/rejecting revisions, any
document with revisions in it can be shown as if all revisions were
accepted, or as if all revisions were rejected. This makes it
possible, for example, to retain revisions in the document to keep
track of its development, but still print it for distribution.
One down side of using revisions is that you could potentially
distribute an electronic version of a doc with the revision
information in it when you do not want to, particularly when the
revisions are collapsed. There is no fool proof way around that, and
my feeling is that if you use revisions then it is your
responsibility to check there are none left you do not want them to
be (revisions never sneak into the document, you have to create
When a new document is created using the File->New command, it is
given a unique id. The document retains this id for the rest of its
lifetime. So if you create a copy of it by using File->Save As, or
just make copy of the file by some copy command, we can compare the
uid's in the two docs and say if they started life as the same
document or not (again, there is nothing sinister going on here, the
uid is just a big random number, it carries no information about who
or where created that document).
We also keep track of some basic information about open/save
sessions. For each open/save session (i.e., once if you open a
document and save it at least once while working on it) we increase
the document version number by 1, store a time when this happens, and
a random id. We also record cumulative editing time for each version
Between the uid and the version history we can tell (a) if two
documents belong to the same family, and, (b) if they do at which
version number (and so when) they became different from each other.
In other words, we can construct family-trees of documents with the
same id (perhaps most useful of this is the abilty to tell that two
documents are identical without having to compare what is in them).
Comparing and merging documents
In additon to the versioning info we can now compare two arbitrary
docs to each other: we can compare their stylesheets, we can compare
their contents and we can also compare their formating.
What is more, we can merge the contents of two documents using
revision marks: having a doc1 and doc2, AbiWord can make revisions to
doc1 that are necessary for it to look like doc2. These are exactly
the same as human made revisions, and can subsequntly be
accepted/rejected in the normal manner or undone using
Undo. (The merging algorithm will need some tuning, but it basically
This archive was generated by hypermail 2.1.4 : Sun Dec 14 2003 - 04:21:33 EST