incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <...@robweir.com>
Subject Re: [Repo][Proposal] OOO340 SVN Dump file import
Date Wed, 17 Aug 2011 23:58:44 GMT
On Wed, Aug 17, 2011 at 5:15 PM, Michael Stahl <mst@openoffice.org> wrote:
> On 16.08.2011 20:41, Rob Weir wrote:
>>
>> During local svn import I received several error messages like this:
>>
>> "svn: Inconsistent line ending style"
>>
>> The following files gave this error:
>>
>> /ooo/trunk/core/dictionaries/de_DE/README_hyph_de_DE.txt
>> /ooo/trunk/core/dictionaries/de_CH/README_hyph_de_CH.txt
>> /ooo/trunk/core/dictionaries/de_AT/README_hyph_de_AT.txt
>> /ooo/trunk/core/gettext/gettext-0.18.1.1.patch
>> /ooo/trunk/core/apache-commons/patches/codec.patch
>> /ooo/trunk/core/libcroco/libcroco-0.6.2.patch
>> /ooo/trunk/core/graphite/graphite-2.3.1.patch
>
>> /ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/body.xsl
>>
>> /ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/styles/style_mapping_css.xsl
>> /ooo/trunk/core/solenv/bin/cwstouched.pl
>> /ooo/trunk/core/readlicense_oo/html/THIRDPARTYLICENSEREADME.html
>> /ooo/trunk/core/writerfilter/source/doctok/escher.html
>
> guess these just need proper consistent EOL.
>
>> /ooo/trunk/core/testautomation/writer/optional/input/import/mactext.txt
>
> this one is called "mactext", maybe it wants mac EOL.
> there is a "dostext.txt" "wintext.txt" "unixtext.txt" in the same dir.
>

Presumably we want these to be come down as-is without any EOL conversion.

The options for the svn:eol-style property are:

native -- store in normalized format, and bring down in client's native style

CRLF -- bring down always with DOS/Windows convention

LF -- bring down in Unix convention

CR -- not sure who uses that? Is that Mac?

But odd that dostext.txt and wintext.txt are different files.  Perhaps
it is testing character set as well?  Might be safer to just treat
these test files as binary files, e.g., set svn:mime-type to
"application/octet-stream".


>> /ooo/trunk/core/hwpfilter/source/hwpeq.cpp
>
> this one has comments with Korean characters in some annoying encoding.
> perhaps we should just remove the offending comments for now.
>
>>
>> /ooo/trunk/core/writerfilter/source/odiapi/qname/resource/office2003/WordprocessingML
>> Schemas/xsdlib.xsd
>>
>> /ooo/trunk/core/writerfilter/source/odiapi/qname/resource/office2003/WordprocessingML
>> Schemas/wordnetaux.xsd
>
> seem to be UTF-16 LE encoded
>
>> Whereas previously I tried to fix these files with dos2unix, this time
>> I simply omitted them from the import.   The automated "one size fits
>> all" approach did not seem right since some of these files, e.g., the
>> mactext.txt, appear to be intentionally using weird EOL conventions.
>>
>> We'll need to resolve these cases individually and add them to the new
>> repository, eventually.  In some cases we might decide to treat them
>> as binary files, in other cases we could dos2unix them, in other cases
>> we'll need to convert the character encoding from UTF-16 to UTF-8.
>> But we can figure that out later.
>>
>> You can download the new dump file from:  www.robweir.com/ooo-dump-new.gz
>>
>> md5sum of the unzipped ooo-dump file is:
>> a6651e98b1a92f5158a08921e85a7a3a
>>
>> -Rob
>
> had a look at it:
>
> - unsurprisingly the files you listed are missing
>
> - some EOL changes in a bunch of files that are probably either harmless or
> an improvement
>
> - similar number of executable files
>  (why the heck are there 8425 of these???)
>
> - also missing: Repository.mk from the l10n toplevel
>  don't actually know if we need that; probably not until the l10n module is
> converted to gbuild, and in any case i guess it could live inside the l10n
> module directory as well.
>
> regards,
>  michael
>
>

Mime
View raw message