The FAQ states that a working copy on NFS server works, and suggests
disabling subtree checking if it does not. As it did not work in my
environment, and disabling subtree checking was not an option, I
tracked down the problem a bit closer:
Having a working copy on a NFS server that re-uses filehanles (like unfsd)
failes. You might consider such a NFS server broken, or you might consider
the NFS client broken, as it writes the content of a deleted file to the
newly created file if the new one reuses the filehandle of the deleted
one (and if less data is written to the new file than the deleted one
contained, garbage will remain at the end of the file which causes
subversion's famous XML parsing error messages).
See also http://bugzilla.kernel.org/show_bug.cgi?id=5085
Subversion could use a simple workaround for such broken systems by
calling ftruncate with size 0 after creating a new file. Any chance
for such a subversion modification? As this question is already
highlighted with a red box in the FAQ, it is surely a frequent
issue. A workaround for the problem in subversion might be a faster
solution than waiting for a potential modifiction of NFS client or
server behaviour.
Best regards,
Hans P. Reiser
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 18 12:26:44 2005