Re: Cleanup? Surely not.

"C. Michael Pilato" <cmpilato_at_collab.net> writes:

> I use sparse checkouts and a from-the-project-root checkout of Subversion.
> A few moments ago, in one shell window, I did this (to fix some WC
> bustedness due to recent but in property handling):
>
> # de-telescope, then re-telescope the 1.6.x directory
> cd projects/subversion/branches
> svn up --set-depth exclude 1.6.x; svn up 1.6 --force
>
> Meanwhile, in another part of the working copy (the trunk), I was running
> 'svn st' in a loop. 'svn st' didn't care so much about the concurrent
> de-telescope bit, but while the re-telescoping was happening, 'svn st'
> produced the following:
>
> $ svn st
> subversion/svn/status-cmd.c:326: (apr_err=155037)
> subversion/svn/util.c:959: (apr_err=155037)
> subversion/libsvn_client/status.c:300: (apr_err=155037)
> subversion/libsvn_wc/node.c:193: (apr_err=155037)
> subversion/libsvn_wc/wc_db.c:4439: (apr_err=155037)
> subversion/libsvn_wc/wc_db_pdh.c:540: (apr_err=155037)
> subversion/libsvn_wc/wc_db_pdh.c:268: (apr_err=155037)
> subversion/libsvn_wc/wc_db_pdh.c:101: (apr_err=155037)
> svn: Previous operation was interrupted; run 'svn cleanup'
> $
>
> That seems like an odd error to me. No 'cleanup' was required -- when the
> 'svn up 1.6.x --force' completed, all was well. But I have no better
> suggestions, and perhaps things are supposed to work this way. So I guess
> this is a drive-by. :-)

This happens when status opens a db betweeen two of the many
transactions that form an update, one that creates a workqueue item
and one of which removes the workqueue item. Status sees the
workqueue item and produces that message. In the past with multi-db
this could happen part way through a status operation, whenever a db
was opened. Now in single-db it can only occur at the start of the
status operation. Since the update is still running it will continue
and clear the workqueue, so a subseqent status might not produce that
error and no cleanup is required.

I'd like status to continue, rather than produce that error message,
perhaps indicating the presence of a workqueue item with 'Q' instead
of, or in addition to, 'L'. I suppose there is a possibility that
status would misbehave if we did this, although 1.6 didn't appear to
have a problem doing this.

-- 
Philip