"Bert Huijben" <b...@qqmail.nl> writes:
>> 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.
>
> In WC-1.0 we left old administrative data in a lot of code paths... (not
> just a few :( ) and in most cases we fix this on adding.
> (Talk about broken behavior...)
In this case it's a real bug that breaks the working copy.
svn rm wc/A/B/f
svn cp wc/g wc/A/B/f
svn rm --force wc/A # doesn't update text-base
svn revert -R wc/A
echo 123 >> wc/A/B/f
svn ci wc # fails with checksum error
> In the final version of WC-NG we don't need most of these operations any
> more.
> * Properties: In DB only. Handled directly. No loggy operation necessary
> * Pristines: Not associated with a single file. No need to remove it in the
> general case. (Maybe schedule a cleanup check as wq item?)
>
> Where the old code 'happens to work' in the intermediate state I wouldn't
> try to solve it cleanly for the period until we have the pristines working.
> (All that work will have to go to /dev/null before 1.7)
Yes, a lot of it gets easier when properties are in the db and
pristines are just a checksum. But mark_tree_deleted will still need
to update the properties and the checksum, and at present it doesn't
do it.
--
Philip
