> -----Original Message-----
> From: Daniel Shahaf [mailto:danielsh_at_elego.de]
> Sent: donderdag 31 maart 2011 11:07
> To: Bert Huijben
> Cc: dev_at_subversion.apache.org
> Subject: Re: svn commit: r1087131 -
> /subversion/trunk/subversion/libsvn_wc/cleanup.c
>
> 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.
Yes, for cleaning up that subdirectory and below; which we can still do in
wc-ng. (Everything was designed to support that).
You just redefined cleanup to cleanup everything above and below that
subdirectory.
> 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?
For wq operations it doesn't matter whenever they run -they are all (or
should be) 100% restartable - so you can just run these whenever you want.
But you can't just remove the working copy locks whenever you want as that
breaks assumptions everywhere. (An svn update 100% assumes that the working
copy doesn't change on its back)
Bert
Received on 2011-03-31 11:40:20 CEST