Bert Huijben wrote on Thu, Mar 31, 2011 at 13:50:45 +0200: > > > > -----Original Message----- > > From: 'Daniel Shahaf' [mailto:[email protected]] > > Sent: donderdag 31 maart 2011 12:01 > > To: Bert Huijben > > Cc: [email protected] > > 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:[email protected]] > > > > 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 >
