Martin Tomes <lists@tomes.org> writes:
> We just had a commit fail with a message saying that a directory was
> not locked. Actually, the commit succeeded but the update of the
> working copy failed. When we tried an svn cleanup it refused to clean
> up saying it couldn't open KILLME because it exists. Having removed
> that file and done a cleanup and update we are left with a lot of
> binary files which are flagged as having a conflict when it looks like
> they don't (the repository version does match the working copy file).
When you say "the update", what do you mean? (Since update is not
part of commit, although some metadata about the committed targets is
changed).
> The directory which was not locked was inside another directory
> which was being deleted.
Concrete examples (i.e., transcripts) are preferable, if you still
have the information.
> This is bad, and there is no obvious way to recover. Files which were
> added and changed are still shown as being added/changed in the
> working copy even though they are in the repository. The only option
> appears to be a new checkout and then a long laborious check to make
> sure all the changes did get committed.
Sorry this happened to you! But, that shouldn't be long and
laborious, it should be easy -- just write a small script to do the
appropriate comparisons. No one should ever have to do such a
comparison by hand.
> What is the best way out of this?
>
> Is this a known problem or is a new Issue required?
I don't think it's known; anyway we'd need more details (the
transcript, or at least the current working copy) to file an issue.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 23 16:51:42 2004