Karl Fogel wrote:
>> o) This very ad-hoc convention is fine for alpha, but I trust it's
>> not intended as the final solution? It has two problems:
>>
>> -) It is unintuitive. It is not obvious to the user why
>> only certain properties are magical in this way based on
>> their name.
>>
>> -) It is too limiting. Why should transcoding only be
>> available to svn: properties? It is useful for user
>> properties as well, so there should be a way to use it.
>>
>>
>
>I'm not sure what to do about the general problem, except to document
>around it. Perhaps we can find a nicer solution after Alpha. Say, a
>configuration option that names which properties get transcoded, and
>the default just happens to include the requisite "svn:" properties.
>
>There may be other answers, though.
>
>We won't get all of this sorted out for Alpha, and that's okay.
>
We can only touch the contents of properties we know about, i.e., the
ones starting with "svn:". Our policy has always been that prop valies
are binary blobs. We mustn't assume anything about the contents of user
props, so we must not touch tnem.
>>*) The --message-encoding option affects decoding of argument to -m
>> and not only messages taken from -F. If this behaviour is correct,
>> the help message should change to reflect it.
>>
>>
>
>I _think_ it is the behavior which should change, will talk it over
>with Ben tomorrow and see if there's a rationale behind the current
>way first.
>
It absolutely makes sense to honour --message-encoding for both -m and
-F. Trust the user: if she writes "svn ci -m foo
--message-encoding=EBCDIC", we must assume she knows what she's doing.
It's not as if someone could add that option by mistake.
If one mistakenly types -m instead of -F, She'll get the wrong message
anyway, not just because the encoding was wrong.
>>*) And finally, I have to ask about the change to check_non_ascii.
>> Not about the && thing, that was obviously just a typo. But what
>> made you decide that a bit test was better than the arithmetic
>> comparison? Readability? Performance? Portability?
>>
>> In fact, the bit test is a teeny bit less portable, because if you
>> (against all reasonable probability) have 9-bit chars for example,
>> the test will miss characters in the range 256-383. While this is
>> technically how the comment says it should work, it's probably not
>> what we want.
>>
>>
>
>It was for performance only. I never knew of a portability issue. Is
>it really an issue anywhere? I thought char was guaranteed to be an
>eight-bit value in ANSI C, but perhaps I'm confusing practice with
>promise...
>
It gets worse. What if the native locale is not some ASCII derivation,
but EBCDIC? Then neither the bit test, nor the arithmetic check will
help. Use (apr_isascii(foo) && !apr_iscntrl(foo)).
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 18 08:11:20 2002