Thanks for the report details... but please keep the dev list cc'd. :-)
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?
> >>*** 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!
> >
> >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 17:17:17 2003