Sean Hussey wrote:
> Recently, I was trying to check out our entire repo (1.3.0) so I could
> rename one of the projects in the root directory.
What client and platform are you using? Most of my experience is with
TortoiseSVN under WinXP.
> When I hit upon a particular file, this happened and stopped the entire checkout:
>
> subversion/libsvn_wc/log.c:338: (apr_err=155009)
> svn: In directory 'berklee_repo/CoolSpool/tags/COOLSPOOL-2/locks'
> subversion/libsvn_subr/io.c:565: (apr_err=2)
> svn: Can't copy
> 'berklee_repo/CoolSpool/tags/COOLSPOOL-2/locks/.svn/tmp/text-base/uchlineRL.lock.svn-base'
> to 'berklee_repo/CoolSpool/tags/COOLSPOOL-2/locks/uchlineRL.lock.tmp':
> No such file or directory
>
> Does this look familiar to anyone? Is there a way to remove those
> files directly on the server?
I don't think this problem has anything to do with the server. Something
got screwed up in your Working Copy cache, in the .svn directory. This
usually happens to us when some WinXP program is holding a NTFS/OS lock
on the local copy of the file, and the Subversion client fails to move
the cached file to the right position, and ends up putting the .svn
directory in a bad state. Sometimes it's so bad that even an "svn
cleanup" command can't fix it.
Our usual quick-and-dirty solution is to delete the offending directory
(the one above the bad .svn folder), and Update one directory higher (to
refresh the Working Copy of the offending directory). If we care about
retaining the local version of any of the files under the offending
directory, we move them away from the Working Copy hierarchy, and then
copy the files back into place after the Update is complete.
I am very interested in hearing about any fixes that are less barbaric!
Thanks,
Jared
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Apr 12 04:15:51 2006