I'd noted the "~" means something odd, but it was always a directory. I
suppose it's possible it wasn't the *same* directory (directory may have
been rm'd and replaced). The messages I saw didn't make this obvious.
How does one recover from a "messed up" working copy? Just create
another working copy?
The recovery was done because, as part of trying to solve the first
problem, I did an svnadmin verify, which aborted before finishing, with
no more error message than "Aborted". This convinced me (right or
wrong), that the repository itself was corrupted. Having svnadmin
recover fail saying you have to run recover was not at all a good sign,
Perhaps none of these are actually data corruption issues, just
usability issues. I'd managed to get something into an odd state (still
don't know how), which wasn't really covered in the docs. Simply adding
something to the doc (or better yet, the error messages) hinting that
the .svn files may be missing would go a long way. Saying something
isn't "locked" doesn't suggest this. Having recover fail saying you
have to run recover is also not a helpful error message.
In any case, I'm happy to hear it probably wasn't a data corruption
From: Ben Collins-Sussman [mailto:firstname.lastname@example.org]
Sent: Sunday, March 28, 2004 5:30 AM
To: James Montebello
Subject: Re: Recovery failure
James Montebello wrote:
> Running 1.0.0 on RedHat9, accessing it strictly through HTTP via
> Everything ran fine for about three weeks (in test mode), being used
> for a few small projects, mostly by one person. Today, a directory
> appeared in svn stat with a '~' marker. svn info says it's scheduled
> to be added (correct). svn commit says that directory is 'not
> locked', and fails. I try svnadmin verify, and it aborts after running
> for awhile. I shut down Apache, and run svnadmin recover, and it
> fails, saying I have to run recover!
> I upgrade to 1.0.1, and the text of the messages are changed, but
> still no fix.
> svn commit says that directory IS locked, and I should run svn
> cleanup. svn cleanup says that directory is not a working copy
> directory. svnadmin recover is still failing saying I have to run
> Doing a dump and load appeared to fix this (so far as I can tell), but
> having the repository corrupt itself in this fashion doesn't exactly
> give me the warm and fuzzies.
> Theories? Comments?
It sounds like you've got at least two completely unrelated problems:
1. your working copy had a "~", which, if you read 'svn help status",
means that something is under version control, but a weird object is in
its place. Like, you scheduled a file for addition, but then before
committing, replaced it with a dir or symlink or something. All of the
"not locked" errors coming from 'svn commit' are caused by this. The
fact that 'svn cleanup' says a directory is not a working copy makes me
wonder if you didn't somehow delete some .svn/ areas by accident
2. did you actually have to do a repository recovery for any reason?
Was the repository actually 'stuck'? Or were you just experimenting,
looking for things to fix that might be related to your working copy
problems? (Your commit problems had nothing to do with a wedged
repository, just a messed up working copy.)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Mar 29 19:21:24 2004