On Mon, Aug 9, 2010 at 7:46 AM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> 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.
The whole point of the pristine store is that the location and
encoding of pristine contents should be transparent to anybody above
libsvn_wc. While making libsvn_wc much easier to maintain and extend,
going that route apparently decreases performance for clients such as
TortoiseSVN by taking away some of the shortcuts they were exploiting.
We need to decide if exposing these shortcuts (and adding the
associated code complexity) is worth it.
In the potential scenario where a user has opted for no pristines or
compressed pristines, how would TortoiseSVN maintain its current
functionality without waiting on decompression or network roundtrips?
-Hyrum
Received on 2010-08-09 16:45:08 CEST