[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: File delete oddities: os delete conflicts wth svn delete

From: Robert North <aqh4uyrs3e02_at_sneakemail.com>
Date: 2003-01-08 13:22:05 CET

Ben Collins-Sussman sussman-at-collab.net |Subversion list| wrote:

>You need to tell us how recent your Subversion is, platform, etc...
>Comments below.
>
>Robert North <aqh4uyrs3e02@sneakemail.com> writes:
>
>
>
Ok I've confirmed to the best of my ability that subversion is correctly
installed.
And Bugs pt 2 & 3 are still present.

So to recap my config:
Subversion is at revision 4276 (Should be==0.16.1)
Running on Suse 8.0 Linux.

I've replied to your comments below.
The fundamental omission I made in my original mail was that in each
bug, "aa" always refers to a directory.
I have also included details about the errors & output generated by
subversion commands.

I also have some simple bash scripts, and logs that demonstate the bugs,
and should be runnable (or at least readable) elsewhere.
If you wish I can post those too.

>
>
>>*** Bug pt2: risks with "svn up aa" ***
>>If my repository is at file:///home/auser/svn
>>Then doing the following causes an unrecoverable failure:
>>svn rm file:///home/auser/svn/aa
>>svn up aa
>>I have attempted "svn cleanup" and "svnadmin repair". Neither correct
>>the failure.
>>
>>
>
>What does "unrecoverable failure" mean?
>

Ok, to be more precise, a working copy cannot be repaired by any svn
commands I know.
(I could be wrong, but I did attempt a whole bunch of wierd & wonderful
things, in addition to
the standard "svn cleanup").

>I can't reproduce this problem:
>
> $ svn rm file:///usr/local/svn/greek-repo/A/B/was_lambda
> Committed revision 95.
> $ cd wc/A/B
> $ svn up was_lambda
> D was_lambda
> Updated to revision 95.
>
Ok my apologies, I forgot to mention that "file:///home/auser/svn/aa" is
a directory.
Files always work, directories do not.

I also forgot to include the error messages for this bug....

Running "svn up aa" returns the following results:

subversion/libsvn_wc/log.c:288: (apr_err=155009)
svn: Problem running log
svn: in directory
subversion/libsvn_wc/log.c:1191: (apr_err=155009)
svn: start_handler: error processing command 'delete-entry' in
subversion/libsvn_wc/lock.c:422: (apr_err=155005)
svn: Working copy not locked
svn: directory not locked (aa)

Now, the wc has locks shown by "svn status" as follows:

  L .
! aa

Attempting to clear the lock by "svn cleanup" gives the following:

subversion/libsvn_wc/log.c:288: (apr_err=155009)
svn: Problem running log
svn: in directory
subversion/libsvn_wc/log.c:1191: (apr_err=155009)
svn: start_handler: error processing command 'delete-entry' in
subversion/libsvn_wc/lock.c:422: (apr_err=155005)
svn: Working copy not locked
svn: directory not locked (aa)

The result of "svn status" is unchanged.

>
>
>
>>*** Bug pt 3: bad flagging of files for delete***
>>if i do:
>> rm -rf aa"
>> svn rm aa
>>It fails, to mark aa as deleted (as expected).
>>
>>
>
>Actually, this is not as expected. A missing file should still be
>able to be scheduled for deletion. And in the latest svn, this works
>fine.
>
>
Once again aa is a directory, so I think this is still the case.

>
>
>>It then proceeds to mark a few other other files/dirs for delete!
>>
>>
>
>Yes, this bug is already fixed, issue #863.
>
>You better upgrade to 0.16.1. :-)
>
As I mentioned above I'm already at 0.16.1 (Got the build a couple of
hours before the announcement! Got myself even more confused :-)
I've run the tests, and confirmed it passes the regression test for #863.

This bug is quite difficult to reproduce, without using the exact
sequence to generate it.
I can provide a bash script that reproduces it on my machine.

Hope this clarifies things.
    -Rob.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 8 13:22:55 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.