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

Re: svn_wc_translated_file3

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Mon, 09 Aug 2010 12:51:44 +0100

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


*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

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.