Following up to myself... Julian Foad wrote: > 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.
That's svn_subst_stream_translated(), I think. > (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); Hmm... the trouble with the WC's idea of "translation" is that converting a "special" (i.e. symlink) node from plain text to an actual symlink is mixed up with the translation of eol-style and keywords which is a streamy operation. Those are the concepts that could do with a bit of separation. - Julian > 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 > >
