On Sat, 2010-08-07, Stefan Küng wrote:
> On 07.08.2010 12:52, Daniel Shahaf wrote:
> > What's the solution?
>
> I'm using svn_wc_get_pristine_copy_path() and disable the deprecated
> warnings for that API call. I won't get a translated file that way, but
> most if not all UI diff tools have options to ignore EOLs. And if
> keywords aren't expanded, well I guess users can live with those lines
> showing up as different when doing such diffs.
>
> Using svn_wc_get_pristine_contents() instead of
> svn_wc_get_pristine_copy_path() is not an option for me here because I
> can't pass a stream to an external diff application. Which means I would
> have to first create a copy of that file (i.e., save the stream), which
> defeats the whole purpose of doing a *fast* diff.
>
> This leads me to another request: would it be possible to 'un-deprecate'
> the svn_wc_get_pristine_copy_path() API?
One problem with all the APIs that provide a path to a pristine file is
they don't promise how long that path will be valid. A subsequent "svn
update" may delete the pristine file even if a diff GUI is still
displaying it. A given diff GUI may or may not have a problem with
that, but the point is it's a poorly defined API behaviour.
There is a change of behaviour in WC-NG. In the WC-1 scheme, running
"svn update" while the pristine file was being viewed would result in
the new pristine text appearing at the SAME path. In the WC-NG pristine
store, running "svn update" will result in the old path possibly being
deleted (but maybe not immediately), and the new pristine text file
being created at a DIFFERENT path.
However, the lack of a specified lifetime isn't a new problem, and maybe
it isn't much of a problem in practice, so maybe we should just keep
these APIs.
> Not a big deal of course, I can use this deprecated API just fine.
You could, but if you have a reason to use an API then it is an
important API and we shouldn't deprecate it without providing a better
replacement. So thanks for sharing this requirement.
I think we should *either* restore/un-deprecate
svn_wc_get_pristine_copy_path()
svn_wc_translated_file3()
*or* define APIs that are similar to these except having some proper way
to guarantee the lifetime of the file at the returned path.
Since the lifetime issue doesn't appear to be that important, and isn't
a problem that's introduced by 1.7 changes, I suggest
restoring/un-deprecating the functions we had, unless and until we have
better ones.
I can do this soon if no better solution is proposed.
- Julian
Received on 2010-08-09 13:52:30 CEST