You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Florian Kolter <fk...@floriankolter.de> on 2012/04/23 16:40:04 UTC
Corrupt working copies with Subversion 1.7.4 in VMWare with shared
folders (two svn processes; malformed sqlite database)
Hello,
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'
not present
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
outside)
- or Subversion is not installed on the host system
My configuration:
- 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
further hints?
Thanks in advance
Florian
AW: Corrupt working copies with Subversion 1.7.4 in VMWare with
shared folders (two svn processes; malformed sqlite database)
Posted by Markus Schaber <m....@3s-software.com>.
Hi, Florian,
Von: Florian Kolter [mailto:fk@floriankolter.de]
> > > 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.
> >
> > Accessing the same working copy from several processes works fine as
> long as the locking works fine.
> >
> > However, locking over network file systems has issues in some cases, and
> > VirtualBox uses network file system emulation for the shared folders for
> > windows guests.
> >
> > So my hint is that you check with the VirtualBox folks whether they
> > know of any issues with locking on shared folders. (Maybe simply
> > updating VirtualBox or the guest utils helps. :-)
>
> Thanks for your tip. I can try to find out what VMWare's implementation
> does or if there is an update.
Of course I meant VMWare folks, and not VirtualBox folks - I just slipped over to VirtualBox as I happen to know how they implemented shared folders...
> However I have been working this way for years with Subversion 1.6 and
> never experienced any problem. Was this kind of locking introduced in
> Subversion 1.7? Because of SQLite?
Yes, using SQLite definitely changed the game. You may google for "sqlite vmware shared folders" or similar to find out whether there are known problems.
But the working copy organization as a whole has changed, and thus it may be some other access pattern which fail on VMWare shared folders.
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: Corrupt working copies with Subversion 1.7.4 in VMWare with
shared folders (two svn processes; malformed sqlite database)
Posted by Florian Kolter <fk...@floriankolter.de>.
Hi Markus,
* Markus Schaber [2012-04-23 14:53]:
> Hi, Florian,
>
> Von: Florian Kolter [mailto:fk@floriankolter.de]
> >
> > 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.
>
> Accessing the same working copy from several processes works fine as long as the locking works fine.
>
> However, locking over network file systems has issues in some cases, and VirtualBox uses network file system emulation for the shared folders for windows guests.
>
> So my hint is that you check with the VirtualBox folks whether they know of any issues with locking on shared folders. (Maybe simply updating VirtualBox or the guest utils helps. :-)
Thanks for your tip. I can try to find out what VMWare's implementation
does or if there is an update.
However I have been working this way for years with Subversion 1.6 and
never experienced any problem. Was this kind of locking introduced in
Subversion 1.7? Because of SQLite?
Best regards,
Florian
AW: Corrupt working copies with Subversion 1.7.4 in VMWare with
shared folders (two svn processes; malformed sqlite database)
Posted by Markus Schaber <m....@3s-software.com>.
Hi, Florian,
Von: Florian Kolter [mailto:fk@floriankolter.de]
>
> 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.
Accessing the same working copy from several processes works fine as long as the locking works fine.
However, locking over network file systems has issues in some cases, and VirtualBox uses network file system emulation for the shared folders for windows guests.
So my hint is that you check with the VirtualBox folks whether they know of any issues with locking on shared folders. (Maybe simply updating VirtualBox or the guest utils helps. :-)
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915