On Wed, Jun 13, 2012 at 10:17:02AM -0500, Les Mikesell wrote:
> On Wed, Jun 13, 2012 at 7:12 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> > The problem is that, at the point where svn runs into this locked
> > file, half of the work has already been done (the metadata in wc.db
> > has already been updated). The remaining work (moving the file into
> > place) is scheduled in a specific table called the work_queue. The
> > work_queue *must* be run to completion to get back into a valid state.
> > It cannot be rolled back (undoing the other part in wc.db), at least
> > not with the current design.
>
> So a process that is supposed to be atomic isn't...
This is not about atomic operations. Modifications made to wc.db state
and on-disk files are not synchronised in an atomic fashion.
The work queue is like a filesystem "journal". It collects changes that need
to be applied to sync the working files on disk (which users edit) with the
state of meta-data in wc.db. Usually, the work queue is run when an operation,
or some subset thereof, completes. 'svn cleanup' runs the work queue, too.
A write-lock on the WC usually implies that some other process is currently
making modifications to the WC and might be running work queue items.
I don't know if Justin's particular case could somehow be detected and
handled in a more automated fashion. But it would be nice if svn did this.
Justin, if you care strongly about this, please add an entry to our issue
tracker[1] that points at this thread in the archives and summarizes the
problem. Maybe somebody will find time to look into this in detail some day.
Anyone is welcome to do so, including anyone who has participated in this
thread so far, and submit concrete suggestions or even patches that address
this issue. Thanks!
[1] see http://subversion.apache.org/reporting-issues.html
Received on 2012-06-16 01:19:52 CEST