[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Remove svn_wc_translated_* ?

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Mon, 05 Jul 2010 17:32:48 +0100

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

This is an archived mail posted to the Subversion Dev mailing list.