On Mon, 2010-07-05, Hyrum K. Wright wrote:
> Julian's r960620 prompted me to do a bit of digging in the client
> library. It turns out there is nowhere we use
> svn_wc_translated_stream3() and svn_wc_translated_file2(), which are
uh, svn_wc_translated_stream2() and svn_wc_translated_file3() ...
> used to allow the client library to grab the keywords- and
> eol-style-translated versions of a file. Are these APIs now obsolete?
> Can they be removed (the most recent versions are new in 1.7)? Do
> other API consumers depend on them?
This doesn't impact directly on whether we should remove the latest
(unused) versions and deprecate the previous versions of the APIs you
mentioned, but ...
I have been thinking the set of "translation" API functions is a bit
ragged. I would like to see a smaller set of API functions with more
distinct tasks, something like just the following pair:
(A) a libsvn_subr API that translates a given stream according to a
given set of properties, not implicitly referring to a versioned node.
(B) a libsvn_wc API that grabs, from a versioned file, the set of
properties necessary for translating it (note that this includes at
least the rev, author, and date as well as the versioned properties
svn:eol-style, svn:mime-type and svn:special);
The purpose is to be able to translate arbitrary stored texts -
especially conflict left/right/mine files stored in the pristine store -
to and from Repository Normal Form without referring to a current
versioned node at the time of translation.
> Relatedly, the one potential use for them is to replace the
> libsvn_client call to svn_wc__versioned_file_modcheck() in merge.c.
> But it feels there is a better solution for that one-off case.
+1 to replacing that private call with some suitable public call. I
expect to see several other places like this appear in the course of
tree conflicts work.
- Julian
Received on 2010-07-05 18:27:05 CEST