Hi all out there!
In a sort of local scalability test (wanted to know with what number
of files in a single commit this would fail or corrupt the repos; with
2100 in a 128MB environment it does not) I got an SVN server
timeout.
This was after all postfix messages and obviously while the
administrative files in the working copy were - or should have been -
updated.
So with the next attempt to commit thereafter SVN told me to
update first for the files in the working copy were out of date though
there had not been any changes, this second commit was just to
see how things were after the SVN timeout. This update copied all
files just committed back to the working copy and reported them
as merged.
This looked like a nuisance only till SVN came upon files added or
deleted with the previous timed out commit. It would not update the
"added" files nor would it delete or restore the "deleted" files. I had
to delete the respective folders to finally get around this. Cleanup
on the working copy had no effect.
I know there is a setting for SVN to timeout. But this can be
approximate at best. One never knows what happens - a slow or
very busy machine, too many files in one commit, broken network
connection. So I would think that cleanup should handle this, too.
Jan Hendrik
---------------------------------------
Freedom quote:
The ultimate test of a belief in free speech
should be whether it can be extended to people you hate.
-- Justice Oliver Wendell Holmes
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Oct 19 12:47:44 2003