Greg Hudson <ghudson@MIT.EDU> writes:
> A possible compromise here is to base64-encode filenames and property
> names in XML documents (and any other externally-provided strings which
> might show up there), which should render Subversion as charset-neutral
> as CVS is.
Certainly. Both solutions work. It's just a matter of selecting
one. As far as I have come to understand, the Subversion project has
chosen the UTF-8 thing.
> I'm... disappointed that you would equate the desire for simple code
> with the desire to coddle programmers.
Well, I don't think that the simplicity will be much affected with the
new wrapper functions you suggested. The programmers still have to be
alert and not use some APR functions directly though.
> We want to eliminate the external diff fairly soon. But even ignoring
> that, aren't the labels just revision numbers or something fairly
> innocuous like that?
When external diff is removed, the svn_io_run_cmd() function can be
removed, and the conversions in it will be gone. No problem.
The labels typically contain the filename.
Anyway, I've added wrapper functions for apr_file_open, apr_stat,
apr_file_rename, apr_dir_make and apr_dir_open. Now the only stuff in
libsvn_client that needs to explicilty do the UTF thing are
add.c: gets directory entries from APR
auth.c: gets username from APR
commit.c: gets directory entries from APR
commit_util.c: debugging code printing to stdout
diff.c: prints stuff on an application provided stream for the user to read
repos_diff.c: calls apr_file_remove from a cleanup handler where normal
error handling might not be appropriate
I'll probably a wrapper for apr_dir_read too, to get rid of the
conversions in add.c and commit.c. Adding a wrapper for
apr_get_username() probably wouldn't make much sense though since it's
only used in two places (once in libsvn_client, and once in libsvn_subr).
As for the debugging code, one could argue that conversions could be
omitted for code that is just for debugging anyway. OTOH, I think
that debugging code should behave as similar to the "real" code as
possible. In any case, this code should probably be completely
removed before long.
Finally, having a wrapper for apr_file_printf might be nice, but
slightly tricky to do right, since you'd either have to print to a
string first (ok, but not so neat) and convert that, or find out which
of the arguments are strings in order to convert them separately.
Hm, I see now that apr_file_printf prints to a string anyway, so
probably the first solution would not be so bad after all...
// Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 24 15:22:08 2002