On 09.08.2010 19:11, Hyrum K. Wright wrote:
On Mon, Aug 9, 2010 at 11:51 AM, Stefan Küng<tortoise...@gmail.com> wrote:
On 09.08.2010 16:44, Hyrum K. Wright wrote:
On Mon, Aug 9, 2010 at 7:46 AM, Julian Foad<julian.f...@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.
Or just 'give me a reference to a file': if it's already available, just
return the path to that file. If it's not available yet, get a copy of that
file (uncompressed or fetched from a repository if it's not available
locally at all) and return the path to that temp file.
Maybe with a flag to keep/remove the file on pool cleanup.
- 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?
I think users will understand if they decide to have their BASE compressed
or not stored locally, that such diffs will take longer.
If I may suggest how the API(s) should look and work:
* rename svn_wc_translated_file2() to svn_wc_translated_filestream() since
it doesn't return a file but a file stream. File streams can only be used by
svn clients directly, they can't be passed on to external applications so
their use is limited.
* new API svn_wc_translated_file3():
svn_client_translated_file(const char ** resultfile,
svn_boolean_t * copyCreated,
const char * wcfile,
svn_boolean_t deleteOnPoolCleanup,
apr_uint32_t flags,
apr_pool_t* pool)
the flags would be the same as now: SVN_WC_TRANSLATE_FORCE_EOL_REPAIR and
SVN_WC_TRANSLATE_FORCE_COPY.
The API would work like this:
if SVN_WC_TRANSLATE_FORCE_COPY and SVN_WC_TRANSLATE_FORCE_EOL_REPAIR is not
specified and the BASE file is available locally and uncompressed, just
return the path to that file.
Else create a temp copy of the BASE file and return that path.
deleteOnPoolCleanup of course would get ignored if the file is available
locally uncompressed and both SVN_WC_TRANSLATE_FORCE_COPY and
SVN_WC_TRANSLATE_FORCE_EOL_REPAIR are not specified.
The bool copyCreated would get set to true by the API if it created a copy
and set to false if it just returned the path to the existing BASE file.
That way, I could get the file very fast if it's possible, but still would
get the file in a slow way if it's not possible.
Whatever we do, I'm -1 on any solution that uses bitflags.
I just suggested those because the existing API uses them. But of
course, using bool params for each of them will work just as fine.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
