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

[Zack Weinberg]

On 8/27/06, Nathaniel Smith <address@hidden> wrote:
> 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'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.

Well, but might we not want to change that in the future?  To, say, a
Subversion-esque directory attribute?  I'm not taking a position on
whether this would be a good idea, mind.

...
> 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

This is what I'm most concerned with atm ... what is a suitably
comprehensive set of changes?

>     * writing something _MTN/log
>     * writing something to _MTN/monotonerc

... these I had not thought of.

>     * 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.

I think they do both get absolutified.  This is why I was saving and
restoring _MTN/options in the code that's there now.


>   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

This seems ... weak?  I was going to construct a reference workspace
using the current monotone and compare the results of the migrate
operation file-by-file.

Another concern is variable preconditions.  For instance, for the
migration that we're actually considering doing right now, it seems to
me wise to test the behavior both with and without an _MTN/work (==
with and without directory skeleton rearrangements).  But one doesn't
want to go _too_ far in that direction...

zw