Revision Lines

    [ revision line
        - a document as an editorial work in progress
        - a line of revised documents
            / analogous roughly to a biological matriline
        - identity of revision line is recorded in a document,
          by the revision-line 'id' attribute, per revision.mod
    [ working document
        - a copy of the latest document in a revision line,
          undergoing modification to produce the next revision
        - a revision line has exactly one working document

    - a text may be composed of multiple, logically interrelated documents
        / for instance, each chapter of the text
          might be stored as a separate document
        - each document has its own, independent revision line
            / i.e. we do not formalize the concept of a multi-document text;
              it is functionally equivalent to multiple single-document texts

    [ revision control system
        / optional during early work on a document; indispensible later

        - if it is to have concrete form, the revision line may be implemented
          by a revision control system (RCS)
        - recording/commiting a modified working copy in the RCS repo
          will store a new variant of the document in its revision history,
          extending the revision line by one
            / there may be multiple working documents sharing the same repo
              (multiple revision lines), but this sharing does not matter
              (they could just as well be in separate repos)

        - the big advantage for recombinant text
          (aside from the usual advantages for any text)
          is to allow reduction of document size
            | by collapsing of meta-data | reindexing of genes
            - eventually, as unused meta-data builds up,
              memory requirements (in file system, or RAM, or both) will exceed supply

            = but that does not require a revision control system, really,
              and we may use a specialized tool to simply offload the meta-data for ancestry,
              or anything else that accumulates, into a single companion XML file

    [ branch
        - a new revision line (branch) may be created from an existing line (the trunk)
        - procedure
            / steps 2 and 3 may be done using textbender's brancher
            1. copy a document of the original revision line
            2. scan and process all sequences of the document as though each
               were just transferred into it, from the original
                - per d/transfer/note.xht#Maintenance-of-Ancestry-Records
                - this detects any mutations that occured in the previous revision line,
                  and records them in transfer ancestry
                    / basically, it acknowledges the work of the previous author
            3. give it a new revision-line 'id'
            4. (optional) reindex the genes, to eliminate unused meta-data records
                / if no RCS is used, this is your only chance, until one is
                - no tool does this, yet

            - when branching an entire repo, repeat this procedure
              for the revision line of each working document in it
            - failure to branch results in lost attribution
              (your work appears to have been done by the original author)
                / branching late is better than not branching at all,
                  and sooner is better than later
                - often, new genes created in an unbranched copy
                  will have erroneous ancestry, appearing as mutations of other genes
                  in the original revision line

        / revision line branching is analagous to repo branching
            / and recombinant genetic transfers are analagous
              to cherry picking of patches/changesets across repo branches
              (more on this analogy, later)