since upgrading svn from 1.6.16 (TortoiseSVN 1.6.15) to 1.7.4
(TortoiseSVN 1.7.6) my working copies are very often corrupted and clean
up can't recover them. Unfortunately this happens sporadically and I
can't reproduce it with a demo repository. But maybe you have an idea.
I'm working inside a VMWare image, accessing the host's working copies
using shared folders. I must not change this special setup.
Can two TSVNCache processes accessing the same working copy (SQLite
database) produce any damage? SVN 1.6.x worked just fine.
I upgraded all my working copies to 1.7, which worked fine. Some commits
later my main working copy stopped working. After a successful commit
the next operations showed errors: files like .svn/tmp/svn-37AB52F1 were
missing. Creating this (empty) file seemed to help for a short time.
But later errors like these showed up and I was stuck:
svn: E155010: Pristine text 'f61edc47662633671fd1d048e2ea11b8fdaf2336'
This happened in several working copies. Clean up shows the same error, commit
shows an empty file list.
I'm often not even able to check out a new working copy:
Error: sqlite: database disk image is malformed
This happens often, but not always. I tried the same checkout several
times and the error appeared sometimes sooner, sometimes later in the
checkout. (My main working copy has 1 GB, checkout downloads 140 MB.)
SVN seems to work if:
- working copies are accessed on the host only (ordinary situation)
- or working copies are stored inside VMWare on drive C: (not visible
- or Subversion is not installed on the host system
- Windows XP (host and guest)
- Clients: Subversion 1.7.4 (TortoiseSVN 1.7.6) (host and guest)
- Server: Subversion 1.6.2
- Repository: https://...
Can you already guess something from this description? Can you give me
Thanks in advance
Received on 2012-04-23 16:40:49 CEST