Greg Stein <gstein@lyra.org> writes:
> Yup. However, your conversion functions take/return svn_stringbuf_t. Yet the
> functions outside of SVN are all 'const char *'. Thus, it makes a *lot* more
> sense for your conversion functions to start with the correct type.
>
> [ and yes: the *implementation* might be a stringbuf, but that can be hidden
> from the API ]
>
> Unfortunately, that is going to be a pretty big change for your patch...
Good point. The stringbuf variants might still be needed somewhere,
but it's simple enough to add a wrapper function which extracts the
->data for you. At least I can use M-x grep to find all the places to
fix. :-)
> I will also recommend that you break the patch into smaller units. For
> example, we can add the UTF-8 conversion functions before *any* other code
> is changed.
Yeah, but that's the bit that's really needs some more work (although
Ulrich Drepper did provide some opportunities for progress here). :-)
The other bits I think will be difficult to break into units,
unfortunately. The strings get passed around a lot, so it's hard to
make a partitioning that doesn't require you to add extra
reverse-conversions. Of course, if we don't care about consistent
handling of 8-bit characters during the merge phase, you could do it
one library at a time, and just ignore the fact that things are not
converted properly. But that would also mean not being able to
test/use 8-bit values in a reliable way during this time, which would
kind of defeat the purpose.
> When you attach patches, please ensure their MIME type is text/plain. If
> your mailer cannot adjust the mime type after attaching, but merely resides
> on a file extension, then just name the patch with '.txt' on the end.
Ok, will do. I'm using Gnus, which asks me about the MIME type, but
so far I have considered the proposed default value ("text/x-patch")
to be appropriate.
> You should also include [PATCH] in the subject line, so that people know
> what is in there and can review it.
Right. I'll try to remeber that.
// Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 23 01:25:27 2002