[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn_fs_delete() vs. svn_fs_delete_tree()

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2003-11-05 01:39:35 CET

kfogel@collab.net wrote:
> "C. Michael Pilato" <cmpilato@collab.net> writes:
>
>>For the life of me, I've never understood why we have both
>>svn_fs_delete() (which only works on files) and svn_fs_delete_tree()
>>(which works on both files and directories) in our public API. Our
>>code always calls svn_fs_delete_tree() because it saves us a 'kind'
>>check. Anyone opposed to losing svn_fs_delete(), and then renaming
>>svn_fs_delete_tree() to svn_fs_delete()? Am I missing something
>>obvious?
>
> There is a difference between the two functions -- one sets a baton
> flag to FALSE, the other sets it to TRUE.
>
> txn_body_delete() uses the flag to behave differently...

Pardon my impudence, Karl, but that was an almost content-free reply, given that C-Mike had already perceived that the two functions are different. :-)

As I read it, the difference is not that svn_fs_delete() only works on files, but that it will delete a directory only if it is empty. In other words, it is like svn_fs_delete_tree() but with a check for emptiness prepended. In a user interface, such a check is usual to try to avoid disaster, but that does not seem appropriate for an API.

svn_fs_delete[_tree] are wrappers around svn_fs__dag_delete[_tree]. svn_fs_delete is indeed not used, except by its test suite, and nothing apart from it uses svn_fs__dag_delete.

C-Mike's idea of losing the non-recursive version sounds OK to me.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 5 01:38:06 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.