You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@codematters.co.uk> on 2002/07/08 16:20:38 UTC
Re: svn commit: rev 2428 - trunk/subversion/include trunk/subversion/libsvn_fs trunk/subversion/libsvn_wc trunk/subversion/libsvn_subr trunk/subversion/libsvn_client
kfogel@tigris.org writes:
> Author: kfogel
> Date: Mon, 08 Jul 2002 01:18:58 -0500
> New Revision: 2428
>
> Modified:
> trunk/subversion/include/svn_fs.h
> trunk/subversion/include/svn_io.h
> trunk/subversion/libsvn_client/add.c
> trunk/subversion/libsvn_client/auth.c
> trunk/subversion/libsvn_client/client.h
> trunk/subversion/libsvn_client/commit.c
> trunk/subversion/libsvn_client/commit_util.c
> trunk/subversion/libsvn_client/copy.c
> trunk/subversion/libsvn_client/repos_diff.c
> trunk/subversion/libsvn_fs/fs.c
> trunk/subversion/libsvn_subr/io.c
> trunk/subversion/libsvn_subr/svn_error.c
> trunk/subversion/libsvn_subr/target.c
> trunk/subversion/libsvn_wc/props.c
> Log:
> Continuing work on issue #494.
>
> Apply the remainder of Marcus Comstedt's `svn_utf_2366_libs.patch',
> with some tweaks. This is the "separate commit" referred to in
> revision 2424. Marcus -- and anyone else -- please review :-).
>
> Note that this leaves the code in a technically broken state until his
> svn_utf_2366_client.patch is applied, which I'll do in an upcoming
> commit. That patch makes the command line client ensure that it's
> passing UTF-8 paths down into the libraries, which are now expecting
> that encoding.
>
> It's only "technically" broken because in practice everything works
> fine, and make check still passes, as long as you use ascii filenames
> and/or don't pass the `--enable-utf8' flag to configure.
Looks like it's "really" broken :-(
I'm seeing lots of failures in the regression tests when configured
without --enable-utf8. Recompiling only utf.c with -DSVN_UTF8 (as
well as relinking) appears to solve the problem. So, although this
patch introduced the failures, I suspect utf.c rather than the files
changed here.
The first test that fails is basic_tests.py number 4.
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2428 - trunk/subversion/include trunk/subversion/libsvn_fs trunk/subversion/libsvn_wc trunk/subversion/libsvn_subr trunk/subversion/libsvn_client
Posted by cm...@collab.net.
Philip Martin <ph...@codematters.co.uk> writes:
> Karl Fogel <kf...@newton.ch.collab.net> writes:
>
> > Philip Martin <ph...@codematters.co.uk> writes:
> > > I'm seeing lots of failures in the regression tests when configured
> > > without --enable-utf8. Recompiling only utf.c with -DSVN_UTF8 (as
> > > well as relinking) appears to solve the problem. So, although this
> > > patch introduced the failures, I suspect utf.c rather than the files
> > > changed here.
> > >
> > > The first test that fails is basic_tests.py number 4.
> >
> > Yes, Mike Pilato just reported similar lossage to me when I got in
> > this morning.
> >
> > Sorry about that, folks.
> >
> > I'm going to revert right away, then work on the problem.
>
> I suspect the problem is that the non-utf8 functions in utf.c
> don't always allocate memory:
I have a local mod that remedies this exact problem, and that seems to
fix `make check' for me. Will commit up soon.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2428 - trunk/subversion/include trunk/subversion/libsvn_fs trunk/subversion/libsvn_wc trunk/subversion/libsvn_subr trunk/subversion/libsvn_client
Posted by Philip Martin <ph...@codematters.co.uk>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Philip Martin <ph...@codematters.co.uk> writes:
> > I'm seeing lots of failures in the regression tests when configured
> > without --enable-utf8. Recompiling only utf.c with -DSVN_UTF8 (as
> > well as relinking) appears to solve the problem. So, although this
> > patch introduced the failures, I suspect utf.c rather than the files
> > changed here.
> >
> > The first test that fails is basic_tests.py number 4.
>
> Yes, Mike Pilato just reported similar lossage to me when I got in
> this morning.
>
> Sorry about that, folks.
>
> I'm going to revert right away, then work on the problem.
I suspect the problem is that the non-utf8 functions in utf.c
don't always allocate memory:
Index: ../svn/subversion/libsvn_subr/utf.c
===================================================================
--- ../svn/subversion/libsvn_subr/utf.c
+++ ../svn/subversion/libsvn_subr/utf.c Mon Jul 8 18:08:59 2002
@@ -365,8 +365,9 @@
const char **dest,
apr_pool_t *pool)
{
- SVN_ERR (check_non_ascii (src, strlen (src), pool));
- *dest = src;
+ apr_size_t len = strlen (src);
+ SVN_ERR (check_non_ascii (src, len, pool));
+ *dest = apr_pmemdup (pool, src, len + 1);
return SVN_NO_ERROR;
}
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2428 - trunk/subversion/include trunk/subversion/libsvn_fs trunk/subversion/libsvn_wc trunk/subversion/libsvn_subr trunk/subversion/libsvn_client
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:
> I'm seeing lots of failures in the regression tests when configured
> without --enable-utf8. Recompiling only utf.c with -DSVN_UTF8 (as
> well as relinking) appears to solve the problem. So, although this
> patch introduced the failures, I suspect utf.c rather than the files
> changed here.
>
> The first test that fails is basic_tests.py number 4.
Yes, Mike Pilato just reported similar lossage to me when I got in
this morning.
Sorry about that, folks.
I'm going to revert right away, then work on the problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org