[rough]
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)