So here I am, been using Subversion for version control since forever (or 2006, whichever is more recent), just checked a new subdirectory in under an existing project...
I decided it would be nice to add a version / build-time message when the firmware signs on. So, I copy the supplemental Make rules over from another project that has such a feature, and I remove the stuff I don't need, and I re-run Make, and it gets to
svnversion -n >> vstamp.c
and svnversion hangs.
OK, so I hit control-C and try again.
Now svnversion can't be terminated nohows. Attempting to do anything with that subdirectory in kdesvn results in a hang.
In the same directory, svn info works fine.
Rebooting the workstation doesn't solve the problem.
Well... since I hadn't added anything important since the last check-in, maybe I should just rm -r that part of the working copy, and then restore it?
This doesn't appear to be a problem anyone else has encountered; at least, I'm not finding anything about it on the Web.
Update: as it turns out, it was an NFS/SAMBA interaction problem; an uncouth Windows application in the next room had held one of the files open for reading, causing it to be locked against some (but not all) forms of access, causing all manner of hilarity.
I was wondering how to determine if there are locked files for you for the next iteration. Although I thought that ls would do it, I was wrong. There is lslk which seems to check all locked files on the box and then I found this which seems a better fit:
http://stackoverflow.com/questions/284950/best-way-to-see-what-files-are-locked-in-subversion
While not a big fan of Windoze, it does show lck files when something puts a lock on a file in FAT32 and above. I've not seen something like that in the *nix world, but did find the lslk mentioned above. I have some loose responsibility for a svn server here so I've written it down in my crib page for future use.
Posted by: Marcus Erroneous | Tuesday, 12 February 2013 at 13:10