"Bert Huijben" <bert_at_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
Received on 2010-01-28 00:17:11 CET