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
>
>
Received on 2010-07-05 18:34:28 CEST