On Thu, 2011-07-14 at 14:54 +0200, Bert Huijben wrote:
> 
> > -----Original Message-----
> > From: Julian Foad [mailto:julian.f...@wandisco.com]
> > Sent: donderdag 14 juli 2011 13:58
> > To: dev@subversion.apache.org
> > Subject: [PATCH] Improve reporting WC is locked/busy ('run cleanup')
> > 
> > The attached patch makes some improvements to how we report that the
> > WC
> > is locked or busy (the 'run cleanup' messages).  I need a sanity check
> > to make sure I've understood the relationship between how we want to
> > handle 'the work queue is busy' and 'there is a write lock on a WC
> > directory'.
> > 
> > When the WC is locked we may (depending on the timing) see:
> > 
> >   $ svn up -q & svn up -q
> >   svn: E155004: Working copy '/home/...' locked.
> >   svn: E155004: '/home/...' is already locked.
> >   svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> > details)
> > 
> > (or, depending on the timing, there may be two 'database is locked'
> > lines instead of the 'is already locked' line), or
> > 
> >   $ svn up & svn commit
> >   svn: E155004: Commit failed (details follow):
> >   svn: E155004: Working copy '/home/...' locked.
> >   svn: E155004: '/home/...' is already locked.
> >   svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> > details)
> > 
> > When the work queue is not empty, we see:
> > 
> >   $ svn status
> >   svn: E155037: Previous operation has not finished; run 'cleanup' if it
> > was interrupted
> > 
> > 
> > My recommendations, mainly for the WQ-not-empty case:
> > 
> > 1.  The 'E155037' message shown above comes from libsvn_wc.  But the
> > part about running 'cleanup' should be added by 'svn', since in other
> > clients it may have a different name or may not be applicable at all,
> > especially if the client can find out that in fact the other operation
> > is still running.  So libsvn_wc would say just:
> > 
> >   "A previous operation on the working copy has not finished"
> > 
> > and 'svn' would wrap that in:
> > 
> >   "Run 'svn cleanup' if the previous operation was interrupted"
> > 
> > See also point (2).
> > 
> > 2.  Consider wrapping this SVN_ERR_WC_CLEANUP_REQUIRED (E155037)
> > error
> > in a SVN_ERR_WC_LOCKED (E155004) error to preserve API compatibility
> > w.r.t. this kind of situation.  Inside libsvn_wc, of course the
> > condition being reported here is not the same as a 'lock', but to an
> > outside caller the net effect is basically that it's a lock.
> > 
> > If we don't wrap this in SVN_ERR_WC_LOCKED, then in order to support
> > (1), 'svn' should learn to recognize the new error code as well, at the
> > point where it determines whether to suggest the user should run
> > 'cleanup'.
> > 
> > 3.  The error code SVN_ERR_WC_CLEANUP_REQUIRED is misnamed, since
> > libsvn_wc does not know whether cleanup is required.  Rename it to
> > SVN_ERR_WC_BUSY or SVN_ERR_WC_WORK_QUEUE_NOT_EMPTY.
> 
> +1 on SVN_ERR_WC_BUSY
> 
> > 4.  libsvn_wc should include the WC root in the error message:
> > 
> >   "A previous operation on the working copy at '<wcroot_abspath>' has
> > not finished"
> 
> This assumes that we only store a single working copy in wc.db, while we 
> designed wc.db to allow storing data for multiple working copies.
> -0 on this suggestion.

OK.

> > 5.  'svn' should print its message about running 'cleanup' via the
> > standard error message mechanism instead of using cmdline_fputs(), so
> > that the message appears in the standard (new) format with the
> > 'Ennnnnn:' prefix.  This suggestion is independent of the others so I'll
> > commit it separately, but it's included in this patch for you to see.
> 
> If this is handled by wrapping the error, you get this for free.
> (I'm not sure if that is what you suggested)

Yes, that's what I mean: just wrap the error so this gets printed in the
standard format automatically.

> > With this patch, typical results are:
> > 
> >   $ svn up -q & svn up -q
> >   svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help
> > cleanup' for details)
> >   svn: E155004: Working copy '/home/...' locked.
> >   svn: E155004: '/home/...' is already locked.
> > 
> >   $ svn up -q & svn commit
> >   svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help
> > cleanup' for details)
> >   svn: E155004: Commit failed (details follow):
> >   svn: E155004: Working copy '/home/...' locked.
> >   svn: E155004: '/home/...' is already locked.
> > 
> > and for the more interesting, WQ-not-empty, case:
> > 
> >   $ svn status
> >   svn: E155037: Run 'svn cleanup' to remove locks (type 'svn help
> > cleanup' for details)
> >   svn: E155037: A previous operation on the working copy at '/home/...'
> > has not finished
> 
> Hmmm....
> 
> Maybe we have a different (much larger) problem here.
> 
> We don't store the wc_id with the workingqueue items, but we do assume that 
> we know the path when we run the wq items...
> (The wq items contain local_relpaths instead of local abspaths)
> 
> Probably easy to fix when we actually start storing multiple working copies 
> in the DB, but I think it is a bug in how we store the data.

Hmm...

- Julian


Reply via email to