On Fri, 2010-10-22, Philip Martin wrote:
> "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.
It sounds like we need a "Re-try if busy" mode of accessing the DB.
(Where "busy" means "still have WQ items".)
> 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
I don't think it's valid to allow an operation like 'status' to continue
while the WQ is non-empty. At least not with the current design in
which the scope of WQ items is not known any more specifically than "may
affect any part of any WC managed by the DB".
If we were to design a way by which a set of WQ items affecting only
subtree A would not block DB access to subtree B, that would be a
different way of solving this issue.
> 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.
Let's not introduce additional status outputs unless it's something the
user *really* needs to know. AFAICT this state is basically the same as
'L' ("WC node is locked") from the user's POV, but different in that
(currently) the WQ is DB-wide, not restricted to a single subtree.
- Julian
Received on 2010-10-28 17:38:12 CEST