I've commit the changes (r1740660). I don't know if the sbadmin package
need to be include with the native/non native management? sbadmin
package could be consider as a 'binary' package?
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.
