Re: some explanations about revisions and related stuff

From: Tomas Frydrych (tomas_at_frydrych.uklinux.net)
Date: Sun Dec 14 2003 - 15:41:59 EST

  • Next message: Tomas Frydrych: "commit (HEAD): xap_Win32Res_DlgListDocuments.rc2"

    Hi Leonard,

    > >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.
    >
    > So there is no "accept revisions" command as there is in
    > Word? When you accept a revision, it removes the old information (if
    > it's a strikeout or replacement) and adds the new.
    >
    > What is Abi doing?

    Yes, there is accept command and it does completely remove that
    revision marking from the document. However, just as in Word you can
    choose not to see revisions when they are present (you see what the
    doc would look like if the revisions were accepted). There were some
    concerns about this and IIRC some company (I think MS) suffered
    embarassements when its PR people released some docs that had
    revisions in them, just not showing and those revisions contained
    some stuff that should not have been let into public domain.

    > >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
    > >number.
    >
    > Every time you save, the version number should be increased...

    I am not convinced about this.

    > >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).
    >
    > Simple comparison of the version ID won't work, however.
    >
    > Create a document (id=???, v==0) and do some writing. Save
    > it (id=???, v==1). Now duplicate the file outside of Abi - you now
    > have two docs each with id==?? and v==1. Edit the first making one
    > set of changes and save (id==???, v==2) and edit the second making a
    > completely different set of change (id==???, v==2). Doc ID's are the
    > same. Versions are the same. Contents are VERY different...

    Sure. I did not explain the details of how it works; each version
    record contains also a random number and we compared UID, version and
    the random numbers.

    > So rather than a simplistic binary diff, you are actually
    > doing a "DOM difference" (no offense to our own Dom, of course ;).
    > Interesting. Are you using any of the well documented
    > XML-differencing algorithms or something specific to Abi's structure?
    >

    Simply deciding whether the contents/fmt are different is quie easy,
    I just work along the two docs until they differ. Deciding how they
    differ is harder and I am going to do some research on such
    algorithms. At this stage, I was more interested in having the basic
    framework within which different algorithms could be tested.

    Tomas



    This archive was generated by hypermail 2.1.4 : Sun Dec 14 2003 - 15:41:51 EST