some explanations about revisions and related stuff

From: Tomas Frydrych (
Date: Sun Dec 14 2003 - 04:21:32 EST

  • Next message: Hubert Figuiere: "Commit (HEAD): MacOS X build fixes"

    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