Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:
> % $svn cleanup
> subversion/libsvn_wc/workqueue.c:672: (apr_err=235000)
> svn: E235000: In file 'subversion/libsvn_wc/workqueue.c' line 672: assertion failed (checksum != NULL)
> zsh: abort $SVN cleanup
> % svnqlite3-dump | grep -i queue
> CREATE TABLE WORK_QUEUE ( id INTEGER PRIMARY KEY AUTOINCREMENT, work BLOB NOT NULL );
> INSERT INTO "WORK_QUEUE" VALUES(5,(file-install filter.d/asf-svn-abuse-warn.conf 1 0 1 1));
> INSERT INTO "WORK_QUEUE" VALUES(6,(file-install filter.d/asf-svn-abuse-ban.conf 1 0 1 1));
> INSERT INTO "sqlite_sequence" VALUES('WORK_QUEUE',6);
> However, I haven't found a way to reproduce an 'svn upgrade' scenario
> that triggers the assertion.
I've been looking at this working copy. It appears to be an update from
r794489 to r795270 (which was probably HEAD at the time).
An update should mark directories 'incomplete' when opening them to make
changes during an update, this gets stored in the op-depth 0 row and is
set back to 'normal' when the directory is closed at the end of the
What appears to have happened is that wc_db.c:open_directory has gone
wrong and put the 'incomplete' marker for 'filter.d' in op-depth 1
rather than op-depth 0. I can reproduce the problem as follows:
$ svnadmin create repo
$ svn mkdir -mm file://`pwd`/repo/A
$ svn import -mm repo/format file://`pwd`/repo/A/f
$ svn import -mm repo/format file://`pwd`/repo/A/g
$ svn co file://`pwd`/repo_at_2 wc
Now run update inside gdb:
$ gdb -arg svn up wc
(gdb) b update_editor.c:open_directory
Switch to another terminal and run:
$ sqlite3 wc/.svn/wc.db "update nodes set presence='normal' where local_relpath='A'"
$ sqlite3 wc/.svn/wc.db "insert into nodes(wc_id, op_depth, local_relpath, parent_relpath, kind, presence) values (1, 1, 'A', '', 'dir', 'incomplete')"
Back to gdb and
At this point "svn cleanup" will produce the same error as the original
I have no idea how wc_db.c:open_directory managed to set 'incomplete' at
the wrong op_depth. It doesn't seem possible since 0 is hard-coded in
the SQL see STMT_UPDATE_BASE_NODE_PRESENCE_REVNUM_AND_REPOS_PATH.
Anyone got any ideas?
uberSVN: Apache Subversion Made Easy
Received on 2011-09-05 19:58:56 CEST