On Wed, May 31, 2006 at 09:28:50AM +0100, Ian France wrote:
I bet this error is easy to reproduce as:
-- put some unknown or ignored file inside a directory
-- update to a revision in which that directory has been removed
Ah, yes. That seems to do it very effectively. Interestingly the newly
added file _is_ deleted in the workspace. It seems to be a problem in
the _MTN/tmp directory rather than in the workspace.
Technically, it isn't deleted, it's just moved to _MTN/tmp :-)
The exact sequence of events is:
-- mtn decides that directory 'foo' should go
-- mtn moves that directory to _MTN/tmp, like 'mv foo _MTN/tmp/7'
this works fine, renaming doesn't care if a directory has stuff
in it
-- mtn deletes that directory from _MNT/tmp, like 'rmdir _MTN/tmp/7'
oops, this step fails, because _MTN/tmp/7 (formerly known as
'foo') is not empty
-- mtn waves its hands in the air and gives up
Also, the tmp directory is not cleared up after the failure, nor when
the next command using it is run.
Right. This is sort-of intentional, we don't have any robust
mechanism for dealing with all these corner cases, so we just sort of
default to never deleting anything -- on the theory that if we're
going to do something totally stupid anyway, it's better to be stupid
in a way that requires user intervention than to be stupid in a way
that silently deletes(!) data.
Really we need a better and more systematic way to deal with these
sorts of issues, though. Probably it should be some sort of conflict?
It's not too unlike the "orphaned file" conflict case...
-- Nathaniel
smime.p7s