> -----Original Message-----
> From: Ivan Zhakov [mailto:ivan_at_visualsvn.com]
> Sent: dinsdag 23 augustus 2011 13:58
> To: Bert Huijben
> Cc: Markus Schaber; dev_at_subversion.apache.org
> Subject: Re: svn upgrade fails with database table is locked
> On Tue, Aug 23, 2011 at 13:01, Bert Huijben <bert_at_qqmail.nl> wrote:
> > > > It's very interesting. It seems that disabling SQLite shared cache fixes
> > > > one problem and discovers another. I'm not WCNG expert, may be
> > > > Subversion developers have more knowledge of possible reason of
> > > node
> > > > .. was not found" error.
> > > >
> > > > Bert do you have any ideas why this could happen?
> > >
> > > Again, I offer to send the zipped working copy to interested developers.
> > > (7zip is 19kb, zip is 114kb).
> > I have a few guesses on what might cause this, mostly related to files that
> should have been deleted before the upgrade.
> > Can you send an archived copy to me?
> > (I would prefer a zip over a 7zip file, but I can handle both)
> Markus provided working copy to me and I was able to reproduce issue
> 1. Checkout working copy with at least one file using svn 1.6
> 2. Lock this file
> 3. Try to run svn upgrade of this working copy.
> You get "database table is locked: NODES" message. More interesting
> that you disable SQLite shared cache you'll get "svn: E155010: The
> node '..' was not found." error. This error occurs in
> entires.c:write_entry() function in call to svn_wc__db_lock_add()
> It seems to be Subversion 1.7.0 blocker.
We use two database handles to the same database in the upgrade code. One contains local changes that the other part of our code (which uses the other handle) wants to see.
With the shared cache SQLite notes the outstanding changes by reporting an error and without it, it doesn't find the expected row.
Received on 2011-08-23 14:21:54 CEST