design q -- are revisions linear or parallel?

From: Paul Rohr (paul@abisource.com)
Date: Sat May 18 2002 - 14:15:30 EDT

  • Next message: Tomas Frydrych: "commit HEAD: ev_UnixKeyboard.cpp"

    I should have asked this earlier, since I don't use the feature...

    When people use the revision marks feature in other word processors, which
    is the most common use case?

    one author, sequential
    ----------------------
      v. 1 -- author A does a bunch of work
      v. 2 -- A does more work
      v. 3 -- A deletes some of it
      v. 4 -- A does even more work
      etc.

    multiple authors, strictly linear
    ---------------------------------
      v. 1 -- A writes something
      v. 2 -- B makes changes to A's version
      v. 3 -- C makes changes to B's version
      v. 4 -- A accepts and rejects some of each contributor's changes
      v. 5 -- B makes changes to v. 4
      etc.

    main author, with parallel reviewers in lockstep
    ------------------------------------------------
      v. 1 -- A writes something
      v. 1.B -- B makes changes to A's original version
      v. 1.C -- C makes changes to A's original version
      v. 1.* -- A merges in B and C's changes to review
      v. 2 -- A accepts/rejects portions of 1.*, adds more
      v. 2.B -- B makes changes to 2, adding variant of stuff rejected from 1.B
      v. 2.D -- D makes changes to 2
      v. 2.* -- A merges 2.B and 2.D for review
      v. 3 -- A claims consensus, publishes another draft for review
      etc.

    parallel, non-linear
    --------------------
      Note that the prior case was still fairly linear, but in the real world,
      things could get even messier. For example, say that just before
      publishing version 3 in the prior case, two more versions arrive:

      v. 1.C.E -- E makes changes to 1.C
      v. 2.B.F -- F makes changes to 2.B

      Ideally, author A would still like to be able to review and integrate
      those changes, right?

    bottom line
    -----------
    I don't know which of the above scenarios are most useful or interesting to
    existing word processor users. Indeed, I suspect it depends a lot on their
    current work habits.

    AFAICT, the design proposals to date all presume a single document with a
    strict linear ordering of versions, and thus would be best suited to the
    first one or two scenarios.

    However, I'd suggest that the further along that spectrum you move, the less
    likely it is that you'll want to embed all those variants *inside* a single
    file. Instead, an external solution which allows you to compare and merge
    two arbitrary versions may prove more useful. Note that you still may want
    a UI for *displaying* the consensus version, of course.

    And now, back to our regularly scheduled design-fest, already in progress.

    Paul,
    trying to find a sweet spot in the design space



    This archive was generated by hypermail 2.1.4 : Sat May 18 2002 - 14:18:01 EDT