Karl Fogel <kfogel@newton.ch.collab.net> writes:
> 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.
If we're going to use property name to distinguish between the
behaviours, then my opinion is that there should be a particular
syntax element to do it, rather than trying to overload existing
syntactic elements of the name (such as "svn:"). To exemplify what
I'm talking about, consider disk files on the C64. If you give a
filename as
FOO,P
then you'll get a PRG (binary) file. If you instead give the filename
as
FOO,S
then you get a SEQ (text) file. So a similar way to handle properties
could be to use names like
svn:ignore,t - text property
svn:icon,b - binary property
Of course, one of the modes should be default so that you can ommit
the mode indicator. I expect text properties will be the most common,
so text mode should probably be default. For binary properties then,
something more aesthetic than ",b" can probably be thought of. Just
as long as it's a syntactic element of its own. Example:
svn:ignore - text property (default mode)
svn:icon# - binary property (due to syntactic marker #)
Well, just one proposal. I expect there will be more. After alpha.
:-)
> > *) 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
So, where does this buy you performance? The only CPU I can think of
where the bit test would be faster is 6502, where the mere act of
LDA:ing somthing would set the N flag in the status register to the
eight bit of the loaded value. On a RISC cpu, I expect the bit test
to be same speed or slower compared to an arithmetic comparison.
(You _could_ make it one cycle faster on the Hitachi SH-4 by removing
the cast to unsigned char *, since unsignedness is not required for
the bit test to work, and reading unsigned chars is one cycle slower
than reading signed chars on that CPU.)
> 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...
C99 guarantees that char is _at least_ eight-bits. It can be 4711
bits without breaking the standard though. In practice, not much of a
problem though. Some PDPs have 9 bit chars, I think. But I don't
expect to find chars any other size than 8 anywhere where svn will
run.
// Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 18 14:07:35 2002