Bert Huijben <b...@qqmail.nl> writes: > All the now deprecated functions now fail unconditionally when the setting > is enabled. Isn’t it possible to do this more graceful whenever a file is > encountered which misses it’s prisite version?
The problem with this approach is that the functions are going to work, but only *sometimes*, and will fail unpredictably, depending on whether a pristine was fetched or removed by any previous API call. With that in mind, failing consistently seems to be a more appropriate choice for a deprecated function than failing randomly. > As far as I know it is expected that some of the files do have pristines, > while others don’t… That would allow things like diffs on old clients that > didn’t switch apis yet. Thinking about this, the currently documented assumption is that a file has no pristine if and only if it's being added/replaced without a copyfrom. So maybe we cannot really extend that to "any file might not have a pristine" without it being an incompatible change. Thanks, Evgeny Kotkov
