Ben Collins-Sussman sussman-at-collab.net |Subversion list| wrote:
>Thanks for the report details... but please keep the dev list cc'd. :-)
>
>
Ahh, the list is Bcc'd in my messages (Apart from this one (cc'd)).
Mozilla allows you to set an auto Bcc up ... so I thought I'd use it
instead of missing the CC totally :-)
But back to the subject in hand....
I've already replied to Phillip (passed your mail in the ether), with an
e-mail containing the bash scripts that reproduce
the bugs.
You might like to look at them.
Now some quick comments on your replies....
>My responses are below...
>
>"rob" <aqh4uyrs3e02@sneakemail.com> writes:
>
>
>
>>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.
>>
>>
>
>Ahhhhh, I see. So you're attempting to explicitly update a directory
>that is now deleted in the repository, right?
>
>Philip, have we seen this issue before? Should I file a new one?
>
Philip has already replied to my mail, and requires some further
clarification.
As I mentioned I have replied to him giving example bash scripts.
>
>
>
>
>>>>*** 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!
>>>>
>>>>
>>>>
>
>Gotcha. I'm aware of this bug, and I'm fixing it as part of issue
>#962 today. (Files work, dirs don't yet.) Keep your eyes peeled!
>
Great!
Cheers
-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 17:34:52 2003