[From users@subversion]
"Steve Dwire" <sdwire@pcsigroup.com> writes:
> -----Original Message-----
> From: Philip Martin [mailto:philip@codematters.co.uk]
> Sent: Thursday, August 21, 2003 8:16 PM
> To: Steve Dwire
> Cc: users@subversion.tigris.org
> Subject: Re: WC locked. Can't cleanup: .svn/tmp/text-base is empty
>
>> "Steve Dwire" <sdwire@pcsigroup.com> writes:
>>
>>> svn: The system cannot find the file specified.
>>> svn: svn_io_copy_file: error copying 'C:/test/Dest/DocStore/Data
>>> Documents/Physicians/.svn/tmp/text-base/713FABD831C4441CB4272DC2E292F
>>> 990
>>> .xml.svn-base' to 'C:/test/Dest/DocStore/Data
>>> Documents/Physicians/713FABD831C4441CB4272DC2E292F990.xml.2.tmp'
>>>
>>> So I decided to do some spelunking, and I find that
>>> .../Physicians/.svn/tmp/text-base is empty. No wonder svn cleanup
>>> couldn't find the file specified. Now I've reached the end of the
>>> FAQ, so I find myself at your mercy.
>>>
>>> How can I recover from this?
>>
>>The most reliable way to recover is to use ordinary OS operations to
>>delete (or move) the Physicians directory from the working copy and
>>then run update. Please look for the log file *before* deleting
>>Physicians.
>
> I tried that, but the working copy was still locked, so I had to run svn
> cleanup first. That finished without complaining, but then a subsequent
> update gives me this:
>
> C:\>svn update C:\test
> svn: Working copy not locked
> svn: directory not locked (C:/test/Dest/DocStore/Data
> Documents/Physicians)
I can reproduce Steve's error using gdb as follows: start with a small
repository
svnadmin create repo
svn mkdir file://`pwd`/repo/foo
svn import svn-config file://`pwd`/repo/foo/bar
Now run "svn co file://`pwd`/repo wc" under gdb and set a breakpoint
on svn_wc__run_log. When the breakpoint is reached delete the file
wc/foo/.svn/.svn/tmp/text-base/bar.svn-base and continue. This
results in a failed checkout, with a locked working copy and a log
file that won't run due to a missing file. It appears to be Steve's
original problem, although quite how the file got deleted is a
mystery.
The way I would expect to recover is to "rm -rf wc/foo" and then
update, but that doesn't work. The working copy reporter doesn't
appear to handle missing directories in an incomplete working copy.
Looking at libsvn_wc/adm_crawler.c:report_revisions:309 I see that the
path foo is correctly identified as missing, but because the
report_everything flag is set the reporter->delete_path call is not
made and an attempt is made to access the missing working copy.
Is this a bug in the incomplete=true handling, or this scenario just
not supposed to happen?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 22 13:11:59 2003