A couple of times now, when checking in a lot of files, I've had
subversion hang during the commit process. That is, the subversion
process is chugging along happily and accepting new connections, but the
actual commit hangs. The file counts when this has happend have bee
around 75, 200, and 500.
In these cases, I eventually kill the client process. This has happened
with both TortoiseSVN and the plain old command line "svn commit".
Either way, it finds the differences, goes through the whole "sending
files" process, and then... sits there. Forever (or at least for more
than an hour, sending and receiving no packets).
When I do kill the process, I find that the revisions have indeed been
committed, but that the post-commit script has not been started (my
script logs its start times). After having to kill the client process,
my working copy is very unhappy, since it thinks that it has not been
committed, but the server thinks it has. After messing with a lot of
"svn cleanup" (cleanup succeeded OK"), "svn commit" (cannot commit file
XXX because working copy is out of date), and "svn update" (cannot add
file XXX because it already exists), I've ended up just deleting my
working copy and doing a new checkout.
This is SVN 1.0.2 running on windows (not the special _svn version, just
the normal one). It has happened with both the svn 1.0.2 command line
client and the release TortoiseSVN client. In all cases, it has been
using the svn:// protocol for repository access.
Has anyone seen something like this? Any advice on how to track it
down? I haven't lost any data, but it's always a bit scary deleting the
local working copy after seeing werd problems committing the changes.
Thanks
-b
Received on Mon May 10 08:56:02 2004