Mailing-List: contact dev-help@jmeter.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jmeter.apache.org
MIME-Version: 1.0
In-Reply-To: <571BAD5E.6040808@apache.org>
References: 
 <CAOGo0VbgGHUFcDMMv7_EYq0WJM-0MLurZK-xvWfvNBu6xXU29Q@mail.gmail.com>
	<571B940B.1060000@apache.org>
	<571BAD5E.6040808@apache.org>
Date: Sun, 24 Apr 2016 13:32:02 +0100
Message-ID: 
 <CAOGo0VasGFTUgC3RQm7a+W7NE=qYtqyYMVdZVW+K4UQTjOeLGg@mail.gmail.com>
Subject: Re: report-template EOL settings for text files
From: sebb <sebbaz@gmail.com>
To: dev@jmeter.apache.org
Content-Type: text/plain; charset=UTF-8

On 23 April 2016 at 18:14, Milamber <milamber@apache.org> wrote:
>
> I've commit the changes (r1740660). I don't know if the sbadmin package need
> to be include with the native/non native management?

native means that the files will be converted to CRLF for the zip and
LF for the tar archive if necessary
(e.g. conversion to LF is not necessary on Unix because native files
will already have LF)

non-native means the files don't change between OSes, so conversion is
not necessary.

> sbadmin package could be consider as a 'binary' package?

That depends.

If its text files are supposed to use the native format (i.e. CRLF on
Windows, LF on Unix), then these files must be flagged as
eolstyle=native, and they must be listed as native in build.xml.

If the text files are supposed to be EOL=LF on all OSes, then they
must be flagged as svnstyle=LF, and listed as binary/non-native in
build.xml.

==

The intention is that Zip archives have the EOL setting appropriate
for Windows (CRLF) and Tar has EOL=LF as used on Unix.

Therefore if you compare the contents of the source tar archive with
the SVN tag workspace on Unix it should agree exactly (no need to
allow for EOL differences).
Likewise if you checkout the SVN tag on Windows, it should agree
exactly with the contents of the source Zip archive.

>
>
> On 23/04/2016 16:26, Milamber wrote:
>>
>> So we need to add svn:eolstyle=LF property and convert to LF if the file
>> used CRLF eol?
>>
>> The files need to be include with this change are (from
>> ./bin/report-template/):
>> ./content/pages/ResponseTimes.html.fmkr: HTML document, ASCII text
>> ./content/pages/OverTime.html.fmkr: HTML document, ASCII text
>> ./content/pages/Throughput.html.fmkr: HTML document, ASCII text
>> ./content/js/graph.js.fmkr: ASCII text
>> ./content/js/dashboard.js.fmkr: ASCII text
>> ./index.html.fmkr: HTML document, ASCII text, with CRLF line terminators
>>
>> ./content/css/legends.css: ASCII text
>> ./content/css/jquery-ui.structure.css: ASCII text, with very long lines,
>> with CRLF line terminators
>> ./content/css/jquery-ui.css: ASCII text, with very long lines, with CRLF
>> line terminators
>> ./content/css/theme.blue.css: ASCII text, with very long lines
>> ./content/css/dashboard.css: ASCII text
>> ./content/css/jquery-ui.theme.css: ASCII text, with very long lines, with
>> CRLF line terminators
>>
>> ./content/js/jquery.tablesorter.min.js: UTF-8 Unicode text, with very long
>> lines
>> ./content/js/jquery.flot.axislabels.js: ASCII text
>> ./content/js/jquery-ui.js: ASCII text, with very long lines, with CRLF
>> line terminators
>> ./content/js/hashtable.js: ASCII text, with CRLF line terminators
>> ./content/js/curvedLines.js: Non-ISO extended-ASCII text, with CRLF line
>> terminators
>> ./content/js/dashboard-commons.js: ASCII text
>> ./content/js/jquery.numberformatter-1.2.3.min.js: ASCII text, with very
>> long lines, with no line terminators
>> ./content/js/jquery.cookie.js: ASCII text, with CRLF line terminators
>>
>> README.TXT: ASCII text, with very long lines, with CRLF line terminators
>>
>>
>> I understand well?
>>
>> Milamber
>>
>>
>> On 23/04/2016 15:13, sebb wrote:
>>>
>>> The fmkr files (and other text files) don't have svn:eolstyle properties.
>>> I suspect the files need either native or LF to avoid problems with ^M
>>> in future.
>>>
>>> Also build.xml may need to be updated to take account of the correct
>>> setting for the fmkr files when creating the archives.
>>>
>>> At present the files seem to be included in "dist.common.non.native"
>>> which means they will retain whatever EOL they happen to have in the
>>> workspace of the RM.
>>>
>>> This is only OK if the EOL of the files does not depend on the EOL of
>>> the host OS; i.e. the files most likely need svn:eolstyle=LF.
>>>
>>
>>
>