anchor.diff:  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   
   install(Nodes) ->
  -    schematool_admin:install(Nodes).
  +    schematool_admin:install(Nodes),
  +    %% printout (is this useful?)
  +    mnesia:info().
   
   load_and_migrate(File) ->
       Schema_key = schematool_admin:load_schema_file(File),
  
positive.code: 
  history() ->
      schematool_admin:view_history().
  
  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  %% Diff schema1 and schema2 (old vs new). Foundation for
  
negative.code: %% rewritten and/or copied. 
  %%
  %% NOTE: to run schematool, see ../bin/schematool.pl
  %%   (For examples, see Makefile for WF or erlmail.)
  %%
  %% This module is the start of schema processing once we
  %% have the schema module compiled and generated.
  %%
  %% The schema is stored in a file foo.schema, which
  %% is preprocessed into foo.schema.term by schematool.pl.
  %% Note that multiple schema.term files can be merged
  %% into a master schema, which is suitable for applications
  %% defining their own local schemas.
  %%
  %% The foo.schema.term file can then be loaded into the
  %% system and viewed among the candidate schemas. The candidates
  %% are indexed by load time, and are stored persistently.
  %%
  %% Finally, the system can migrate to a candidate schema.
  %% This takes a backup of the system tables, perform the
  %% changes and stops with the new model. If migration fails,
  %% the system rolls back to the backup and possibly restarts.
  %% (This is entirely handled by the migration process).
  %%
  %% Internally, schematool adds a small number of internal
  %% tables to hold information such as the candidate schemas,
  %% a changelog and some internal values.
  %%
  %% Advanced topics:
  %% - qlc
  %% - automatic accessors (using indexes etc, in a
  %%   single consistent notation) = query language
  
  %% STATUS
  %% - creates schema from spec routinely (on 1 node)
  