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 19:09:03 CEST