anchor.diff:  All we need to know for now: _all_ data lines in the weave are newline
   terminated.
   
  -In BitKeeper, CR ('\r') are stripped from the end of the data tokens
  -before storing (s/\r+\n/\n/).  An old bug was that the \r was not
  +In BitKeeper, CR (`\r`) are stripped from the end of the data tokens
  +before storing (`s/\r+\n/\n/`).  An old bug was that the `\r` was not
   stripped in the initial checkin.  For that reason, new versions of bk
  -need to be able to store and keep the \r in the weave, as it was part of
  +need to be able to store and keep the `\r` in the weave, as it was part of
   the file checksum.  That doesn't matter much for weave discussion, just
   a nuance in the structure of a BK data token.  BTW, new versions of bk
  -do strip the \r on initial checkin. 
  -
  -Weave creation
  ---------------
  +do strip the `\r` on initial checkin. 
  +
  +=== Weave creation
  +
   In SCCS, the simplest form of adding a new block of data is creating
  -the initial file (the weave part done in slib.c:checkin()).
  +the initial file (the weave part done in 
  +http://www.bkbits.net/u/bk/bugfix/src/slib.c?PAGE=anno[`slib.c:checkin()`]).
   
   The new delta is assigned the first serial number: 1
  -The data is wrapped in an I-E pair
  -
  -^AI 1
  -line 1
  -line 2
  -line 3
  -^AE 1
  +The data is wrapped in an `I-E` pair
  +
  +----
  +^AI 1
  +line 1
  +line 2
  +line 3
  +^AE 1
  +----
   
   An empty file is encoded with no data:
  -^AI 1
  -^AE 1
  +----
  +^AI 1
  +^AE 1
  +----
   
   In BK, the first delta is the rootkey, and has no data.  The first data
   bearing delta is serial 2.  This lead to BK files taking the above ideas,
   and with the first serial being 2 and an empty 1 block at the end:
   
  -^AI 2
  -line 1
  -line 2
  -line 3
  -^AE 2
  -^AI 1
  -^AE 1
  +----
  +^AI 2
  +line 1
  +line 2
  +line 3
  +^AE 2
  +^AI 1
  +^AE 1
  +----
   
   And an empty file looks like
   
  -^AI 2
  -^AE 2
  -^AI 1
  -^AE 1
  +----
  +^AI 2
  +^AE 2
  +^AI 1
  +^AE 1
  +----
   
   At some conceptual level, none of these lines are needed, but since they
   are there, we can build into integrity checkers that they must be there.
  
positive.code: ^AE 2
  ^AI 1
  ^AE 1
  
  Now, being brilliant as you are, you are thinking, but what if
  I deactivate 6, add a new block after line 2, and reactivate 6?
  Looking like:
  
  ^AI 3
  new line
  ^AI 5
  
negative.code: ^AE 2
  ^AI 1
  ^AE 1
  ----
  
  Note, if I had no deactivated serial 4 and had a file:
  
  ----
  new line
  a parallel new line
  another new line
  line 1
  line 2
  line 3
  ----
  
  We would get the same weave.  This is a big point: the weave doesn't
  record what is active at the time: no mention of what is the line following
  new lines.  To be taken advantage of later.
  
  So that's it for adds -- go to a line, put `I` .. data .. `E`
  
  === Delete
  
  
  Let's remove line 2:
  
  ----
  new line
  a parallel new line
  another new line
  line 1
  line 3
  ----
  
  diff -an:
  ----
  d5 1
  ----
  
  Reads as delete line 5 in the old file for 1 line.
  
  In SCCS, deletes are done by putting the `D` command before the desired
  data and `E` after the desired token:
  
  ----
  ^AI 3
  new line
  ^AI 5
  