Re: [Monotone-devel] Problems with _MTN/tmp

[Ian France]

Nathaniel Smith wrote:
> On Tue, May 30, 2006 at 09:47:10AM +0100, Ian France wrote:
>
> > mtn: expanding selection 'h:com.example.newbranch'
> > mtn: expanded to '879ff04f5e5aed535f2c2fb3419393c32b451bf2'
> > mtn: selected update target 879ff04f5e5aed535f2c2fb3419393c32b451bf2
> > mtn: dropping somepath/somefile.java
> > mtn: dropping anotherpath/anotherfile.java
> > mtn: dropping anotherpath_but_a_directory_this_time_not_a_file
> > mtn: error: could not remove '_MTN/tmp/3'
> > mtn: error: Directory not empty
> >
> > Curiously, IMHO, the _MTN/tmp/3 directory contained a backup of one of 
> > the files dropped above. i.e. anotherpath/anotherfile.java~
>
>
> 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.

Also, the tmp directory is not cleared up after the failure, nor when 
the next command using it is run.

> The update will remove any versioned files contained in that
> directory before attempting to delete the directory, because any rev
> in which the directory has been removed no longer has those files in
> it (obviously).  But monotone won't know to touch any unknown or
> ignored files in the directory, so when it goes to remove it for real,
> they screw things up.

> Workspaces are annoying :-/.  This is another place where it'd be nice
> to be able to rollback a failed workspace modification.  I wonder what
> other systems do here.
>
> -- Nathaniel