hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [VOTE] HttpComponents Client 4.2.6 release
Date Tue, 03 Sep 2013 16:28:54 GMT
On 3 September 2013 12:34, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Tue, 2013-09-03 at 10:57 +0100, sebb wrote:
>> On 3 September 2013 10:48, Oleg Kalnichevski <olegk@apache.org> wrote:
>> > On Tue, 2013-09-03 at 02:03 -0400, Karl Wright wrote:
>> >> Hi Sebb,
>> >>
>> >> "It is essential that the files in a source release can be matched
>> >> against those in SVN."
>> >>
>> >> I think that's technically not necessary according to Apache rules;  what's
>> >> necessary is that the bits in the tar or zip be based *solely* on the svn
>> >> tag and upstream dependencies.  But you really vote not on the tag but on
>> >> the tar and zip.
>> >>
>> >> "But the main issue I have is that the PNG file in the ZIP archive is
>> >> corrupt."
>> >>
>> >> I think that should be fixed.  It's also worth considering that perhaps
>> >> fixing up line endings for Windows users is maybe not worth the pain in
the
>> >> behind at release time that it is.  Most people use editors these days that
>> >> don't care.
>> >>
>> >> Karl
>> >>
>> >
>> > Karl
>> > Line delimiters of all human readable files as well as source code get
>> > adjusted based on the type of the distribution. The whole thing boils
>> > down to a just a few _resource_ files, which I personally think should
>> > never be meddled with given that line delimiters may be semantically
>> > significant.
>>
>> If a fixed eol is required by resource files, they should not have
>> eol-style:native in SVN.
>> They should have either LF or CRLF depending on which eol is required
>> by the format.
>>
>> But if the format requires different EOL for Windows and Un*x, then
>> native is correct and so is conversion to the appropriate ending.
>>
>> I am not saying that every text file needs to be converted.
>> But ones which are converted by SVN (i.e. native) should be converted
>> for the corresponding archive.
>>
>
> All which the assembly script has no way of knowing.

In theory the build script could parse the output of svn pl -v and use
that to control the eol massaging.
I agree that would be tedious; it's a lot easier to create the
archives, check the results and then fix any errors.

But the point is, we already know that all the .txt files and all the
.properties files are flagged as eol:native, so we should do the same
in the build script.

Otherwise the generated zip and tar.gz file contents will depend on
the EOL setting for the host where the SVN tag is checked out.

> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message