Re: [Monotone-devel] Last test to fix!

[Daniel Carosone]

On Tue, Feb 27, 2007 at 05:40:28PM -0800, Nathaniel Smith wrote:
> On Tue, Feb 27, 2007 at 02:28:13PM +0100, Richard Levitte - VMS Whacker wrote:
> > Hi,
> > 
> > I've one last test to fix, ws_ops_with_wrong_node_type .  It fails at
> > line 19, and honestly, this test looks weird!  First, the directory
> > "dir2" is created but not added (therefore not versioned), then
> > there's an attempt to rename the file "file" into that unversioned
> > directory, and it was apparently expected to succeed!  Did monotone
> > really allow that, ever?  Would it make sense for it to allow such an
> > operation?
> > 
> > I'm thinking that if monotone ever allowed a versioned file to be
> > renamed into an unversioned directory, it is a bug that has apparently
> > been corrected since.  I'm changing the test accordingly.
> 
> Theory -- it was doing something like
>  $ mkdir foo
>  $ touch bar
>  $ mtn add bar
>  $ mtn mv bar foo
> And expecting that mtn would, at the end of this, expect that there
> existed a file (not directory) named "foo", that should be versioned?
> Hence the test's name, which suggests that it is somehow testing what
> happens when mtn and the workspace disagree on the file vs. directory
> status of some versioned entity?

Quite likely -- and similar behaviour *did* change recently, at least
for no-clobber updates.

A lot of mostly unrelated tests were changed because they
inadvertently relied on files getting clobbered as revisions were
moved around, eg via revert_to().  This does't sound like one of those
tests, but we might have changed it during the same sweep and might
have stopped it making sense in the process.

But I think Nathaniel's theory is right, and that's what this test was
testing.  As for desired behaviour, I think it's best that we
warn/fail on all such workspace conflicts asap: it would be awful if
the results of the above sequence were different if the final step was
"mtn mv -e bar foo".  We might wind up with a revision with a file
foo, and a workspace with a file in foo/bar.

Several folks here know well what I would say next about solving this
whole class of issues using more information in workspace rosters
(rather than bespoke checks scattered in random commands), so I won't :)

--
Dan.

pgpSAE1un_zpd.pgp
Description: PGP signature