Subversion Error Help

Question

I updated the library of third-party developers and transferred the new version to my SVN server. There have been many changes (years worth). At the end of the commit, I received the following message:

... lots of stuff ... Commit succeeded, but other errors follow: Error bumping revisions post-commit (details follow): In directory 'D:\Documents and Settings\scottb\Desktop\imageen' Error processing command 'committed' in 'D:\Documents and Settings\scottb\Desktop\imageen' Error getting 'affected time' for 'D:\Documents and Settings\scottb\Desktop\imageen\.svn\text-base\ImageEn.cnt.svn-base' Can't stat 'D:\Documents and Settings\scottb\Desktop\imageen\.svn\text-base\ImageEn.cnt.svn-base': The system cannot find the file specified. 

So, the first line shows that this happened. But what do other errors mean and do I need to do something to fix them? Is the repository currently damaged? Will I have problems with future changes?

In case this is important, I use TortoiseSVN 1.6.7 Build 18415, Subversion 1.6.9 (client), and the server - Subversion 1.6.5. I had no other problems with these tools.

This is a wonderful verbose error message that has no useful information. Thanks for any info on this!

Answer 1

This seems to have just been a client-side issue and has not affected the server. I simply deleted the specified directory and ran the UPDATE command. The directory has been recreated and reloaded, and now everything looks fine.

Answer 2

Perhaps this is due to the case sensitivity of Subersion, as I see imageen and ImageEn in the log. This may be helpful.

Answer 3

I had the same error "Can not stat {xml file}", but I had a different reason. Visual Studio lock was included in my file. When I closed Visual Studio, it released the lock in the xml file, and I was able to mark the parent of this folder as deleted (received a red x).

Before this problem, I went to TortoiseSVN> Delete and deleted a huge folder tree. But the folder in which this file was located did not delete the status, because Visual Studio held this lock.