[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Last test to fix!
From: |
Daniel Carosone |
Subject: |
Re: [Monotone-devel] Last test to fix! |
Date: |
Wed, 28 Feb 2007 15:09:55 +1100 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
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