On Aug 26, 2007, at 9:32 PM, William A. Rowe, Jr. wrote:
> If the local utf-8 (or someday, utf-16le or utf-16be) file adds a
> byte order mark, and the svn:eol-style is native, and the repository
> copy contains no such mark, and they use a (new optional) config flag;
>
> [miscellany]
> bom-style-native = yes
>
> could we kindly keep their BOM data to their local machine, and strip
> it from the committed file?
Sounds good, but incomplete. I agree that the industry situation
(conflicting standards, popular non-compliant implementations, enough
history to squelch any hope of convergence) is strikingly similar for
BOMs as for line endings. But it's not enough to protect non-BOM-
users from the BOM, we must also provide a BOM for those who expect
it: not only strip it from the commit, but add it to the checkout/
update. I'm not clear why there should be a new config flag, but
there might ought to be a new property: BOM behavior is not "eol-
style," being not at the eol, even though the disagreeing platforms
happen to line up in largely the same camps. Perhaps renaming
"svn:eol-style" to "svn:text-style" would cover both....
Tangentially, I think this is solely a UTF-8 problem, isn't it? ISTR
the 16le/be specs explicitly require the use of the BOM. An
implementation that does not do so would be non-compliant, and I
don't really expect that out of, say, the Linux community. The UTF-8
problem is that the standards do not specify the use of a BOM, but MS
does it anyway.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 27 18:48:03 2007