Subversion freezes during a Linux working copy update process
Saturday, December 1st, 2007Tip: make sure you don’t have any symbolic links between files with (almost) the same names that might have been deleted during the update.
It’s probably a pretty rare situation where you have two files with the same name residing in the same directory where the only difference between their names is the case, eg File.ext and file.ext. In my situation I was forced to create a couple of symbolic links of that kind because I was developing an application on a Linux virtual machine where case matters and the main copy of the application was running on a Windows box. Some other bits of the system were written by developers who apparently did not pay much attention as to whether they refered to File.ext or file.ext, therefore the need for symbolic links.
But the problem arose during a standard svn update procedure when after running the ls -l command I noticed the following:
total 1
lrwxr-xr-x 1 user group 8 1 Dec 14:06 File.txt -> file.txt
whereas before you’d have got:
total 2
lrwxr-xr-x 1 user group 8 1 Dec 14:06 File.txt -> file.txt
-rwxr-xr-x 1 user group 8 1 Dec 13:16 file.txt
I understand what happens here is that Subversion deletes file.txt during the check out and, for some reason, the whole process freezes. I found a simple solution to this issue by simply removing the dead symbolic link (rm -f File.txt). After that’s been done, the subversion update continues its work without any problems. Unless it doesn’t delete another link target file of that kind…