[Monotone-devel] wrapping up the changeset branch

[graydon hoare]

hi,

I'm happy to announce that after almost 5 months of work, the changeset 
branch is now more or less functionally complete. this includes 100% 
testsuite passing, cvs importing, netsync, and code to upgrade old 
databases to the new abstraction.

for the next week or two -- depending on timetables -- I'll be doing 
documentation on the new code, and merging the few residual changes from 
the trunk. I will then release a "monotone 0.15" which is fully 
changeset/revision based, and hopefully return to the normal monthly 
release cycle.

to recap what this rather significant change does:

  - deletes the patch_set, rename_set, ancestry cert, and rename
    cert abstractions

  - removes MT/manifest from the working copy (sniff sniff), leaving
    MT/revision and MT/work in its place. this will probably change
    again slightly when we support merge-into-dir, which we're close
    to being able to do.

  - introduces a new pair of abstractions: change_set and revision.

    - a change_set is a blob of text containing:
      - a path_rearrangement, which describes add/del/rename
        operations on files, and del/rename operations on directories
      - a delta_map, which describes edits made to a tree after the
        path_rearrangement has been applied
    - change_sets can be concatenated, merged, and inverted

    - a revision is a blob of text containing:
      - a manifest ID
      - a set of edges, each of which is:
        - a previous revision ID
        - a previous manifest ID
        - a change_set describing the edge
    - revisions are stored by ID, which is just a hash of their
      normalized text.

   - because a revision ID integrates its parent IDs, revisions
     naturally form a DAG, in which each revision *includes* the
     history of how it came to be, as part of its identity. this
     makes certain operations faster -- the revision DAG is now a
     matter of fact rather than something to infer based on trust --
     but increases the rate of tree divergence a bit. the hunch is
     that it will not increase divergence *much*.

   - in practical terms, most of the command-line arguments which
     used to be manifest IDs are now revision IDs. most certs (author,
     changelog, date, testresults, branch) are attached to revisions
     rather than manifests.

the change essentially narrows the gulf you must cross to switch back 
and forth between the "arch view" of a history-as-a-sequence-of-events 
and the older "monotone view" of a history-as-a-sequence-of-tree-states. 
in a sense it is a capitulation to everyone who said that synthesizing 
changesets on the fly was inefficient and had awkward corner cases. 
there was some truth to that, and I'm happy to say the most awkward bits 
are no longer with us.

previously monotone could kinda-sorta synthesize a change-set-y thing 
between two manifests, but it could get confused with renames, trust, 
ancestry graph cycles, etc. this should no longer be the case: a 
revision is a clear statement of *both views*, tree-states and 
change-sets, simultaneously. it thus contains a bit of redundant 
information, but this should serve at worst as a sanity check and at 
best a serious optimization. I hope that it will allow a tasteful 
resolution to arguments over which view is better. it certainly makes a 
lot of algorithms simpler to have both sides of the duality present in a 
single data structure.

as far as upgrading databases goes: it is imperfect and a bit lossy, but 
it seems to work. please *please* keep a copy of your pre-upgrade 
database. the process degrades all previously recorded rename operations 
to delete/add events. it re-signs all trusted certs with *your key* 
(whoever is doing the upgrade). both these actions do distort history 
somewhat; but imo the "more important" part (who made changes, which 
tree states were involved) is preserved. this was a risk taken by using 
an "alpha quality" VC tool, I'm sorry. I don't think it can be made to 
do 100% conversion.

it is also, unlike previous migrations, a two-step process:

  $ monotone db migrate        # normal part, just adds tables etc.
  $ monotone db changesetify   # temporary command, undocumented

anyways, if you'd like to give it a spin, I'd appreciate any feedback. 
the branch is net.venge.monotone.changeset, hosted in my server on 
venge.net / off.net.

-graydon