repository seemingly corrupted after "abort: Operation not permitted: 'path_to_directory' "

[j. van den hoff]

hi list,

first time in several years of (not too fancy) hg usage that seemingly  
something really bad happened.

a) the setup:
I have a repository (purely local, not connected to any other repo, backup  
is done otherwise...) containing a modestly deep file tree with some  
hundred files, mostly shell scripts. the repo is 3 years old with some 500  
revisions over all. over time there has been substantial restructuring
done, all with `hg mv'  as far as I recall. moreover, there are a bunch of  
untracked files in the tree (test files etc.)

b) problem 1 (the small one):
when trying to do `hg up' to some quite old revision I get an abort due to  
some untracked file not matching to earlier state of repo (to something to  
that extent). question: what is that about? why does mercurial care about  
some untracked file at all and does not leave it alone? ultimately, I  
simply deleted the (unimportant test-)file and this error went away (for  
now, at least), but still..

c) problem 2 (the BIG one):
after getting rid of problem 1 I restored the repo + working copy from  
yesterdays backup (just to make sure that I start over with a definitely  
uncorrupted setup) and tried again to `hg up' to the old revision. this  
failed with "abort: Operation not permitted: 'path_to_directory'"
where `path_to_directory' is the path to one of the subdirs in the current  
working copy. after this abort `hg' believed to be still at `tip' but the  
working copy was severely corrupted in several places (i.e. a diff vs. the  
backup showed many discrepancies). especially the `path_to_directory'  
reported by the abort was simply empty. issuing `hg up tip' did not help  
either. trying to update to "tip minus one" produced multiple conflicts of  
the type

remote changed {some_path_here} which local deleted
use (c)hanged version or leave (d)eleted?

which I did not try to really understand or resolve ...

so the working copy (if not the repo?) seemingly has ended up in an  
inconsistent or severely corrupted state. my only solution was to again  
retrieve the backup and start over.

I could also identify the most recent revision where the problem occurs if  
an update to that revision is attempted: it is the one _before_ which I  
moved some of the tracked files to a new directory. it's exactly that path  
is with reported by the `abort' message as not allowing the operation  
(whatever it is). so I can only update back until the oldest revision  
where the (then) new sub-directory was created and the respective tracked  
files moved to that new directory. the update to the revision before this  
rename/move is not reachable.

btw: I verified that I do not have a stupid permission problem here:  
everything is owned by me and writable AFAICS.


I hope the description is sufficiently clear. did'nt find anything in the  
mailing list archives so that's why I'm here...

I would of course appreciate any help/clarification what might be going on  
here.

thanks in advance

joerg

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/