monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Nathaniel Smith
Subject: Re: [Monotone-devel] Problems with _MTN/tmp
Date: Tue, 30 May 2006 06:25:39 -0700
User-agent: Mutt/1.5.11

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

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

-- 
"...these, like all words, have single, decontextualized meanings: everyone
knows what each of these words means, everyone knows what constitutes an
instance of each of their referents.  Language is fixed.  Meaning is
certain.  Santa Claus comes down the chimney at midnight on December 24."
  -- The Language War, Robin Lakoff




reply via email to

[Prev in Thread] Current Thread [Next in Thread]