Hello,
I've searched the archives and didn't find anything similar to a very
serious problem I encounter for the second time.
We have a team of about 40 accessing a central repository in the LAN
via the svn:// protocol. We're a game development shop, and more than
half of the team are artists, who work with huge files by version
control system standards; we have many files in the tens of megabytes
range, and lately they've been creeping into the hundreds of
megabytes. The entire repository is about 45 GB in
about 35000 revisions. The problem I'm about to describe has happened
on some of the biggest files in the repository, between 150 and 200 MB
in size. Our client machines are fairly similar to each other, all of
them running 32-bit XP on reasonably modern hardware. The machine is
another fairly reasonable modern machine running 32-bit Windows Server
and svnserve.exe as a service via FireDaemon.
What happens is that sometimes, under unclear circumstances, it
becomes impossible for one particular machine - a different one on
each of the two occurrences of the bug - to update a particular folder
- again, a different one each time. For one of the largest files in
the folder, after a lot of waiting, the following message is
displayed:
svn: Can't move 'Rock_04\.svn\tmp\Rock_04#03.OBJ.tmp.tmp' to
'Rock_04\.svn\tmp\Rock_04#03.OBJ.tmp':
The process cannot access the file because it is being used by another process.
(In this case, the original file is called Rock_04.OBJ, in a folder
called Rock_04 - everything else in the filenames is something added
by the Subversion client.)
This happens both with TortoiseSVN and the svn.exe command-line
client. I updated Subversion on the client from 1.4.0 to 1.4.5,
without any changes for the good. The server is still running 1.4.0.
This happens directly after clean restarts of the machine, with all
kinds of "evil" software (antivirus software) stopped.
It also happens when checking out the exact same folder to a fresh location.
At the same time, other machines in the company are able to update the
folder and retrieve the huge file, with no discernible difference
between the machines.
Both times I've "solved" the problem after many hours of banging my
head around it looking for workarounds, by deleting the offending file
directly in the repository, as both times it occurred with OBJ files,
which are an intermediate format and we can live without having them
stored in the repository at the price of one additional export step
anytime anyone needs to work on that particular art asset; our other
art files are smaller, and maybe that's why I haven't seen this on a
file we can't live without. However, sooner or later our original art
files WILL grow to the size where we've experienced this problem,
which will render Subversion unusable with our current workflow.
Has anyone encountered this?
Any ideas?
Should I bump this to the dev@ list?
Best regards,
Assen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-01-20 07:53:04 CET