Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of gcaiod-ooo-dev@m.gmane.org
 designates 80.91.229.12 as permitted sender)
To: ooo-dev@incubator.apache.org
From: Michael Stahl <mst@openoffice.org>
Subject: Re: [Repo][Proposal] OOO340 SVN Dump file import
Date: Wed, 17 Aug 2011 23:15:24 +0200
Lines: 74
Message-ID: <j2hb1c$nbm$1@dough.gmane.org>
References: <4E4A104D.8090905@gmx.net>
 <CAP-ksoiPL_Yjd-1OyTFTpKbtXK7PhjQs-HY+pBSShrshxU37FQ@mail.gmail.com>
 <20110816124813.GA23676@daniel3.local>
 <CAP-ksoi=1b-2P=ZzJfx6fDYWKGNG5ScOUU=xLb_YnUVeQ4a=Qw@mail.gmail.com>
 <CAP-ksogryinUT7hRkJQ8EsfU4mg_8iikYOSv=SzqiQmf2URfcg@mail.gmail.com>
 <1313507919.87657.YahooMailNeo@web113509.mail.gq1.yahoo.com>
 <20110816154430.GA6529@daniel3.local>
 <4bd76f18838bd9401bf62c98c4c532e0@tutopia.com>
 <CAP-ksohCbMEef5ahzZMczQHXCwKpvY9vGGWBg0t93nmAxQwCFQ@mail.gmail.com>
 <20110816170338.GA11173@daniel3.local>
 <20110816175920.GC3800@ulungele.erack.de>
 <CAP-ksogVsqitSS82Xp4072aQqTwDnCiJzGNkjJcHx6C1PuHeAg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:5.0) Gecko/20110707 Thunderbird/5.0
In-Reply-To: 
 <CAP-ksogVsqitSS82Xp4072aQqTwDnCiJzGNkjJcHx6C1PuHeAg@mail.gmail.com>

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.

> /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