Bert Huijben wrote on Thu, Mar 31, 2011 at 10:01:13 +0200:
> > -----Original Message-----
> > From: danielsh_at_apache.org [mailto:danielsh_at_apache.org]
> > Sent: donderdag 31 maart 2011 1:13
> > To: commits_at_subversion.apache.org
> > Subject: svn commit: r1087131 -
> > /subversion/trunk/subversion/libsvn_wc/cleanup.c
> > Author: danielsh
> > Date: Wed Mar 30 23:13:24 2011
> > New Revision: 1087131
> > URL: http://svn.apache.org/viewvc?rev=1087131&view=rev
> > Log:
> > Resolve an instance of issue #3835, concerning 'svn cleanup' of a path under
> > the wc root failing, while 'svn cleanup /path/to/wc/root' works.
> > * subversion/libsvn_wc/cleanup.c
> > (cleanup_internal): Remove TODO comment.
> > (svn_wc_cleanup3): Calculate the wc root and operate on it.
> > Modified:
> > subversion/trunk/subversion/libsvn_wc/cleanup.c
> > Modified: subversion/trunk/subversion/libsvn_wc/cleanup.c
> > URL:
> > http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/clea
> > nup.c?rev=1087131&r1=1087130&r2=1087131&view=diff
> > ==========================================================
> > ====================
> > --- subversion/trunk/subversion/libsvn_wc/cleanup.c (original)
> > +++ subversion/trunk/subversion/libsvn_wc/cleanup.c Wed Mar 30 23:13:24
> > 2011
> > @@ -87,8 +87,6 @@ cleanup_internal(svn_wc__db_t *db,
> > /* Can we even work with this directory? */
> > SVN_ERR(can_be_cleaned(&wc_format, db, adm_abspath, iterpool));
> > - /* ### This fails if ADM_ABSPATH is locked indirectly via a
> > - ### recursive lock on an ancestor. */
> > SVN_ERR(svn_wc__db_wclock_obtain(db, adm_abspath, -1, TRUE,
> > iterpool));
> > /* Run our changes before the subdirectories. We may not have to recurse
> > @@ -145,6 +143,10 @@ svn_wc_cleanup3(svn_wc_context_t *wc_ctx
> > NULL /* ### config */, TRUE, FALSE,
> > scratch_pool, scratch_pool));
> > + /* Always cleanup from the wc root, even when invoked on child. */
> > + SVN_ERR(svn_wc__db_get_wcroot(&local_abspath, db, local_abspath,
> > + scratch_pool, scratch_pool));
> > +
> > SVN_ERR(cleanup_internal(db, local_abspath, cancel_func, cancel_baton,
> > scratch_pool));
> I'm not sure if I like this new behavior; maybe we should just provide a better error message telling you where to update? (Or maybe also a notification so third party application can capture the path without parsing the error message)
> If you are running an svn update in one part of your working copy and run svn cleanup on some other part, running cleanup will now break your svn update by stealing its lock(s).
> This was a fully supported scenario in 1.6.
Running 'svn cleanup' in a versioned subdirectory was also a fully
supported scenario in 1.6.
Isn't this the price we pay for our design choice of single db? i.e.,
unless it's designly sane to ask the wq runner to run only the wq items
pertaining to a subtree of the working copy?
Received on 2011-03-31 11:07:41 CEST