"Bert Huijben" <b...@qqmail.nl> writes: >> * subversion/libsvn_wc/wc_db.c >> (kind_map): Add "none". > > Why did you add a 'none' value? > > svn_wc__db_kind_t doesn't have a none value, and the database schema > doesn't allow a none value?
The code allows the value "none" to get into the database. The path is entries.c:insert_working_node calling svn_node_kind_to_word which can return "none". > (Most likely the bug is where you saw this value) Copy a file: $ svnadmin create repo $ svn import -mm Makefile file://`pwd`/repo/foo $ subversion/svn/svn co file://`pwd`/repo wc $ gdb -args subversion/svn/.libs/lt-svn cp wc/foo wc/bar (gdb) b svn_wc__entry_modify2 (gdb) r Breakpoint 1, svn_wc__entry_modify2 (db=0xf7aec0, (gdb) fin Run till exit from #0 svn_wc__entry_modify2 (db=0xf7aec0, 517 err = svn_wc__entry_modify2(loggy->db, Value returned is $1 = (svn_error_t *) 0x0 (gdb) shell echo "select * from working_node;" | sqlite3 wc/.svn/wc.db 1|bar||normal|none||||||infinity||1|foo|1|||0||0 (gdb) The next call to svn_wc__entry_modify2 would abort if svn_wc__db_read_info read the value "none" from the database. This didn't happen if access batons were being used and the old entry could be retrieved from the access baton cache, which is why the old code didn't fall over. > This type doesn't map to svn_node_kind_t as Greg determined can't > add new values to this existing enum without breaking most of our > other code. svn_wc__db_kind_t is an internal type that is directly > mapped to the database value and this would always write the > "unknown" string in the database. (In most cases this value would be > invalid, except for a few cases where the repository decides not to > tell the workingcopy the node kind) I'll see if I can work out how to get it write "unknown" instead. We currently enforce this constraint when reading but not writing, that's fragile. Why does entries.c:insert_working_node allow invalid values into the database? Is this a bug? Should it be changed to enforce constraints like this? -- Philip
