You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@codematters.co.uk> on 2003/08/22 11:10:59 UTC
Is this a bug in the incomplete=true handling?
[From users@subversion]
"Steve Dwire" <sd...@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" <sd...@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
Re: Is this a bug in the incomplete=true handling?
Posted by Ben Collins-Sussman <su...@collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:
> Index: subversion/libsvn_wc/adm_crawler.c
> ===================================================================
> --- subversion/libsvn_wc/adm_crawler.c (revision 6827)
> +++ subversion/libsvn_wc/adm_crawler.c (working copy)
> @@ -306,10 +306,11 @@
> recreate it locally, so report as missing and move
> along. Again, don't bother if we're reporting
> everything, because the dir is already missing on the server. */
> - if (missing && (! report_everything))
> + if (missing)
> {
> - SVN_ERR (reporter->delete_path (report_baton, this_path,
> - iterpool));
> + if (! report_everything)
> + SVN_ERR (reporter->delete_path (report_baton, this_path,
> + iterpool));
> continue;
> }
It looks perfect! Exactly what I was suggesting.
If it solves your reproduction-recipe bug and passes 'make check',
definitely commit it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Is this a bug in the incomplete=true handling?
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> You're in a situation where wc -does- contain the entry for foo, but
> foo is missing on disk. Our 'low confidence' report logic falls down
> here. You're right, Philip... one step ahead of me. If the entry
> exists in the parent, but is missing from disk, we need to *not* tell
> the server about it in a low-confidence report.
>
> But now I worry what will happen if the server then tries to resend
> the directory, but the entry for it already exists in the
> parent... will that break?
I think it will work, after all "rm -rf ./foo/ && svn up ." works when
incomplete=true is not set.
How about this:
Index: subversion/libsvn_wc/adm_crawler.c
===================================================================
--- subversion/libsvn_wc/adm_crawler.c (revision 6827)
+++ subversion/libsvn_wc/adm_crawler.c (working copy)
@@ -306,10 +306,11 @@
recreate it locally, so report as missing and move
along. Again, don't bother if we're reporting
everything, because the dir is already missing on the server. */
- if (missing && (! report_everything))
+ if (missing)
{
- SVN_ERR (reporter->delete_path (report_baton, this_path,
- iterpool));
+ if (! report_everything)
+ SVN_ERR (reporter->delete_path (report_baton, this_path,
+ iterpool));
continue;
}
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Is this a bug in the incomplete=true handling?
Posted by Ben Collins-Sussman <su...@collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:
> 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.
Ok, I follow you so far.
> The way I would expect to recover is to "rm -rf wc/foo" and then
> update, but that doesn't work.
Ah, yes, sure.
> 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.
The 'report_everything' flag is exactly what should be happening --
it's the "low confidence" reporting mode that an 'incomplete' flag
should trigger.
> Is this a bug in the incomplete=true handling, or this scenario just
> not supposed to happen?
Well, it sounds like you're experiencing a bug, but the part you
describe above is normal.
Here's what *should* happen:
* 'incomplete' flag on wc dir should cause adm_crawler to run with
'report_everything' flag.
* The first reporter command sent should be a set_path() call with
the 'start empty' argument set.
* wc has no other entries to list via set_path, so we call
finish_report().
* the server should now have a transaction that models the wc
correctly -- just an empty dir -- and thus know to send back the
missing directory.
Ahhhhh.... *now* I bet I can predict the bug.
You're in a situation where wc -does- contain the entry for foo, but
foo is missing on disk. Our 'low confidence' report logic falls down
here. You're right, Philip... one step ahead of me. If the entry
exists in the parent, but is missing from disk, we need to *not* tell
the server about it in a low-confidence report.
But now I worry what will happen if the server then tries to resend
the directory, but the entry for it already exists in the
parent... will that break?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Is this a bug in the incomplete=true handling?
Posted by kf...@collab.net.
Philip Martin <ph...@codematters.co.uk> writes:
> 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?
I think the fact that removing-a-directory-and-updating doesn't work
the same way removing-a-file-and-updating does is a bug, though not a
horrifying one.
What happens if one tries to check out the directory in place as a
workaround? Does svn trip up when trying to add its entry in the
parent, because the entry is already there?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org