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

Re: svn commit: r919460 - filtering svn patch targets

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 12 Mar 2010 10:34:51 +0100

On Fri, Mar 12, 2010 at 12:05:48AM +0000, Julian Foad wrote:
> Stefan Sperling wrote:
> > Right now, the tempfiles will be closed on pool cleanup.
> You mean "will be deleted on pool cleanup"?

> > My idea was to specify svn_io_file_del_on_close instead in case
> > tempfiles is not NULL. Which would mean that we should leave them
> > open when returning to the caller.
> The caller can't (properly) close an open file unless you give the
> caller the (open) file handle, not just the file name.

Oh, right.

> > But we can pick either or svn_io_file_del_on_pool_cleanup (depending
> > on the result_pool) or svn_io_file_del_on_close. I don't really mind
> > either way.
> >
> > Can you explain why you would want the files already closed? Just curious.
> If you're going to hand someone an "open file", that either means an
> (open) handle to the file, or it means a filename of a file that some
> OTHER code path has an open handle to. If the former, where is the file
> pointer (beginning, end, undefined)? If the latter, what is the sharing
> mode (can the caller also open the file)?
> In other words, it's just wierd. Either give the path of a (closed)
> file, or give a stream (positioned at the beginning, ready to read
> from).

Fine. Either way would work for me.
But who is responsible for cleaning up the temporary files?
The caller of svn_client_patch() or a pool cleanup handler installed
by svn_client_patch() at the result_pool provided by the caller?

Received on 2010-03-12 10:35:30 CET

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