[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: Daniel Rall <dlr_at_collab.net>
Date: 2007-02-14 18:55:22 CET

On Wed, 14 Feb 2007, Malcolm Rowe wrote:

> 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.

You don't misunderstand me, and are spot on.

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

I do find the new API useful along the lines of 'rm' vs. 'rm -f'.
It's a rather common situation in programming that the target of a
deletion may not exist; having a shorthand to handle this situation is
certainly not required, but is a nice convenience. *shrug*

- Dan

  • application/pgp-signature attachment: stored
Received on Wed Feb 14 18:55:37 2007

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