> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: donderdag 31 maart 2011 1:13
> To: [email protected]
> 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.
Bert
