[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-08 18:12:38 CET

On Thu, 08 Feb 2007, Peter Lundblad wrote:
...
> > The log message seems to be missing most of the changes to libsvn_*/.
> > While most of them are just 'update callers', I would have thought you'd
> > mention the change in libsvn_wc/adm_files.c where the key part of this
> > change was made.
> >
> Of course. I accidentally removed two lines too much from the original
> log message;) Fixed.
 
I still have this change (and complete change log message) sitting in my WC
at the office, but I fell sick, and haven't been in to commit it since
discussion with eh completed.

Thanks for committing it, Peter.

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

- Dan

  • application/pgp-signature attachment: stored
Received on Thu Feb 8 18:13:30 2007

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.