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

Re: RFC: building eol and encoding support into svn_stream_t

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2004-10-17 23:48:34 CEST

> While svn has been localized, several encoding bugs have been found, we
> have some open that are hard to solve, I'm sure we will introduce new ones
> and there are probably more that we haven't found yet.
> I think this is partly because we have different ways of recoding and
> end-of-line translating text in different places:

[ enumeration of all methods used for creating output ]

> Also,
> some functions need to turn off recoding for parts of their output.
> Examples are proplist -v and diff where we might not know the encoding of
> the propval or the file contents.

> I think this is a real mess that we have to fix in some way.

Yup. I even started this. But then you started messing with the same
files (UTF-8 translation speedup) and I decided to toss the work and
stall until yours was done. I didn't get back to it yet.

> My proposal is to add support for recoding and eol translation to our
> svn_stream_t interface. Then we should use streams instread of apr_file_t
> whereever possible, such as in svn_client_diff. It should be possible to
> set the encoding for a stream and turn it into text/binary mode.

> Why not just stack a recoding stream onto an existing stream like we do
> for compression? That's because the creator of the stream knows the
> encoding it should be outputing, but the user of the stream may need to
> turn it into binary mode.

Right. This is exactly the approach I was using. This is not a
solution for the use-case of libsvn_diff however: There you have some
output which needs recoding and some which doesn't. All that needs to
end up in the correct order in the output stream. I was still thinking
about what to do there, but I think there are 2 solutions: tell the
diff lib which encoding the header should be, let it recode and send
the output (just as it is now) to the stream. Or you can add a
callback. Tell the client you are passing it header or file
information and let the client decide what to do....

> Since the stream objects are opaque to the outside world, I think we can
> add encoding information to it without breaking any compability.
> I'd like to get this done for 1.2, so we can get correct and consistent
> output from our commands on all platforms.

I'd love to have it done by 1.2 too. There is an issue for these
recoding problems in the issue tracker already, so if any relevant
discussion comes from this thread, we could add a link to it there.

> Comments?

+1 on dealing with this.
> Regards,
> //Peter



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 17 23:48:45 2004

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.