On Mon, 2010-08-09, Julian Foad wrote:
> On Mon, 2010-08-09, Bert Huijben wrote:
> > Stefan Küng wrote:
> > > This leads me to another request: would it be possible to 'un-deprecate'
> > > the svn_wc_get_pristine_copy_path() API?
>
> > One of the ideas of WC-NG (which will most likely not be part of 1.7, but
> > can be added later without really updating our current pristine api) was to
> > allow compressed and/or (partially) absent pristine storage.
> >
> > This specific api function requires that the file is available in the
> > pristine store as uncompressed file or that we store a copy of the file in a
> > tempfolder (see the documentation update from Julian in r983593).
>
> Ah, yes - I'd forgotton that. When the pristine file already exists in
> plain text, it's not a big problem to return its path even though we
> can't promise how long it will live. But if pristine texts are stored
> compressed and so we have to create a temp file in order to support that
> API, when would we delete the temp file?
A good answer could be: let the caller of
svn_wc_get_pristine_copy_path() specify one of:
- Give me a new copy of the file that I can keep indefinitely and
delete when I wish.
- Give me a reference to a shared copy of the file; keep it available
until pool clean-up.
- Give me a reference to a shared copy of the file; keep it available
until I call ... some new "unreference it" API?
Would the second or third of those options work well, Stefan?
We'll need to consider this within Subversion as well. If we start
supporting compressed bases, we might want to cache non-compressed
copies of some of them for faster access.
A caller of svn_wc_translated_file2() has some control over its output
file lifetime with a default behaviour of delete-on-pool-cleanup and a
SVN_WC_TRANSLATE_NO_OUTPUT_CLEANUP flag to avoid that. However that
only applies when it's making a new copy of the file. The behaviour
when it returns a reference to the shared file is undefined. I've
updated the doc string in r983593 to say so. Thus this function also
needs attention.
- Julian
Received on 2010-08-09 14:46:46 CEST