Re: [Monotone-devel] All operations that affect a workspace

[Nathaniel Smith]

On Sun, Aug 27, 2006 at 10:29:40PM -0700, Zack Weinberg wrote:
> In order to do generic exhaustive testing of workspace migration I
> need an exhaustive list of all the state that can be held in a
> workspace, i.e. all the changes-relative-to-the-base-revision that are
> somehow stored there.  This is what I know about:
> 
> * File content change
> * Rename a file
> * Add a file
> * Drop a file
> * Change an attribute on a file
> * Add an attribute to a file
> * Drop an attribute on a file
> * Add a file to the ignore list
> * Remove a file from the ignore list

I'm not sure if ignore list stuff needs to be considered "workspace
state", exactly, since it's controlled entirely by the ordinary
versioned file .mtn-ignore.

If the question is "what state is stored in _MTN?", then what I can
think of is:
  * base revision
  * pending tree changes (anything mentioned in cset.hh...), currently
    found by reading _MTN/work and scanning the tree
  * _MTN/log may contain a pending commit message
  * _MTN/options contains branch, database, key, and keydir (?)
  * _MTN/inodeprints contains the "inodeprint cache", which is
    not very important (can be regenerated at will).  Its existence is
    used to determine whether inodeprints mode is enabled, however.
  * _MTN/monotonerc is read as a lua hook file.

...I think that's it.  We also use _MTN/debug as a place to drop crash
logs, and _MTN/tmp/ as a temporary store while applying updates, but
neither of these "hold state" in the sense that we write them in one
run, and read them in another.

I guess a test following the model of tests/schema_migration would:
  generate its test workspace by:
    * checking out some base revision, making some changes to it
    * writing something _MTN/log
    * writing something to _MTN/monotonerc
    * filling in _MTN/options -- probably want to do this by hand,
      to avoid issues with the database field (and maybe the keydir
      field?) being absolutified.
  define its "are these two workspaces the same?" test as:
    * both give the same output for "mtn automate get_revision"
    * both have the same _MTN/log
    * both have the same _MTN/monotonerc
    * both have the same _MTN/options

-- Nathaniel

-- 
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould