Svn cleanup was only designed for recovering from a locked workingcopy.
So yes, this is really expected behavior.
You should only run cleanup when it's necessary and when you are sure
no other commands are operating on your wc. See svn help cleanup and
the subversion book.
Bert Huijben (Cell phone) From: Daniel Shahaf
Sent: donderdag 31 maart 2011 19:08
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 13:50:45 +0200:
>
>
> > -----Original Message-----
> > From: 'Daniel Shahaf' [mailto:danielsh_at_elego.de]
> > Sent: donderdag 31 maart 2011 12:01
> > 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 11:39:43 +0200:
> > > > -----Original Message-----
> > > > From: Daniel Shahaf [mailto:danielsh_at_elego.de]
> > > > 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.
> >
> > I'm not concerned about the "when", I'm concerned about the case that
> > the wq contains work items affecting /foo/bar while I'm trying to cleanup
> > /foo11/bar39.
>
> Working queue items 'may run at any time'. So just running them from cleanup
> is safe; whatever path they touch.
>
But then we're back to 'cleanup' touching other subtrees, aren't we?
Consider:
* workqueue item for A2/D/G/alpha
* 'cd A; svn cleanup B/E'
Wouldn't cleanup have to flush that wq item first?
And, of course, wouldn't it need some sort of lock under A2/D/G while
operating on alpha?
> The real problem is that cleanup steals all write locks below the passed
> path for you: Which may (and most likely will) break your working copy when
> operations are in progress.
>
'Break' as in 'corrupt'? I'd hope not --- can we make scenarios such as
% svn up foo &
% sleep N && svn cleanup foo
% svn up foo &
% sleep N && kill -9 $!
yield a recoverable state?
(where by 'recoverable' I imply 'without a fresh checkout')
> Bert
>
Received on 2011-03-31 20:07:30 CEST