"Bert Huijben" <b...@qqmail.nl> writes: > My current code is just a copy of the old code, moved to a new location. No > fixes there. (It still uses svn_wc__entry_modify2). > > In the rest of libsvn_wc we still rewrite BASE_NODE and WORKING_NODE records > from just the limited state in svn_wc_entry_t... and that would reintroduce > the issue anyway. > > If we can fix this for the case where we write from the entries that would > be nice. > > The real solution is stopping to write from entries, which takes much more > effort. > (I counted at least a dozen cases where we still change the scheduling via > entries yesterday... And then there are all those other calls for other > changes). > > I would suggest focusing on removing those entry write operations before we > can focus on the nicest format in the database.
My plan was to write a svn_wc__db_temp_op_delete that modified the WORKING_NODE table directly, without calling entry_modify2. I have such a patch but it doesn't handle all the cases where delete can be called. It was the complexity of this that lead me to create the file notes/wc-ng/transitions--that's my attempt at describing what svn_wc__db_temp_op_delete should do. One other thing that worries me is that mark_tree_deleted seems to doing deletes without doing the loggy/workqueue stuff. If I delete a replaced file svn_wc_delete4 sets up a workqueue item to handle the text-bases. However if I delete a directory containing a replaced file it handles the file with a simple call to entry_modify2--that can't be right. It's not a new bug, it pre-dates wc-ng, but it means that the entry_modify2 calls in mark_tree_deleted cannot simply be replaced by svn_wc__db_temp_op_delete, we need to setup wq items in some cases. -- Philip
