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

[Nathaniel Smith]

On Mon, Aug 28, 2006 at 12:01:58AM -0700, Zack Weinberg wrote:
> 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.

Either way, it'd still be versioned data, and it seems like a
reasonable assumption that _workspace_ migration will never be
fiddling around with versioned data?

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

The list of possible changes is in cset.hh :-).

I wouldn't get too hung up on this, though -- it's hard to imagine
what possible workspace format change would make it possible to, say,
translate renames correctly, but screw up deletions.  The workspace
code now and in the future will presumably just manipulate the list of
changes as a blob, using the same code everything else in monotone
uses.

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

Nod.  I'm pretty sure that we'll happily except workspace-relative
paths here, though; just writing those in by hand might be better.  We
do _want_ to make sure that branch and database, in particular, come
through unscathed -- these are important pieces of information, and
it's easy to imagine them ending up in a different place in the
future.

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

Yeah, and inodeprints are like that too... but to be honest, I have
some difficulty convincing myself that this is something that could
possibly go wrong; the code path for a non-existent _MTN/work is to
just pretend that it is empty, right, and everything downstream works
exactly the same?

-- Nathaniel

-- 
"Of course, the entire effort is to put oneself
 Outside the ordinary range
 Of what are called statistics."
  -- Stephan Spender