"Bert Huijben" <bert_at_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
Received on 2010-02-18 13:54:27 CET