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

Re: svn commit: r23370 - in trunk/subversion: include libsvn_client libsvn_fs_base libsvn_fs_fs libsvn_repos libsvn_subr libsvn_wc tests tests/cmdline tests/cmdline/svntest

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2007-02-14 12:13:01 CET

On Thu, Feb 08, 2007 at 09:12:38AM -0800, Daniel Rall wrote:
> > > More importantly, though, I'm not sure that the API change to
> > > svn_io_remove_dir() is appropriate. Is there any reason that the single
> > > caller who wishes to ignore ENOENT can't simply ignore that error?
> >
> > The difference is that the new function let's make sure that the directory
> > actually doesn't exist afterwards. In general, we could have an ENOENT
> > further down in the tree and in that case, ignoring the error would leave
> > a half-removed directory. I think this behaviour can be more generally useful
> > in cleanup actions, hence the new API.
>
> I noted the same thing while reviewing this patch; the new API is more generally
> useful, so worth the change.
>

Unless I misunderstand what you're suggesting, we could have created
a specific error to distinguish an ENOENT at the root of the deletion
(which indicates a 'normal' condition, merely that the directory doesn't
exist) from an ENOENT midway through the deletion (which indicates
an unexpected problem), which is something we could have done without
revving the interface.

But if we think that the API is generally useful, let's keep it (I'm not
convinced myself, though :-)).

Regards,
Malcolm

  • application/pgp-signature attachment: stored
Received on Wed Feb 14 12:13:20 2007

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