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.
pgpfBZVFds3Iw.pgp
Description: PGP signature
_______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
