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
