"Jan Hendrik" <jan.hendrik@bigfoot.com> writes:
> 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.
I *think* I follow you here... But an exact transcript (or even one
from memory) would be very helpful.
> 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, can you file an issue for this? I think there's a way we can
write a reproduction script, by using a pre-commit hook that just
blocks for N minutes, where N > client-timeout-threshold. I'm not
sure we absolutely need a repro script, if we have a transcript and a
description, even...
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Oct 20 16:37:01 2003