On Fri, 9 Apr 2010, thron7 wrote:

>> For that it will help to at least have consistent EOL style in all files
>> (and I guess any current existing differences, if any, should be
>> considered
>> a bug).
>
> This is taken care of as we run through all relevant framework files
> before packaging up the SDK.

Good.

>> It might (!) be useful to provide two different SDKs, one with Unix and
>> one with Windows kind of eol style.
>
> We had this before (I think until early 0.8.x releases), but many people
> (me included!) were happy that we got rid of platform-specific packages. 
> I think it's simply not worth it.

It shouldn't be difficult to generate them automatically during packaging,
but perhaps there is really no need for it.

>> And for this it would certainly be useful to have SVN handle the variants
>> by using the 'native' eol handling as Derrell already pointed out (and
>> again I think any deviations from the SVN native propery should also be
>> considered bugs and fixed).
>
> Again, I think it's not worth it. eol-style:native is a nice feature, but
> maintaining it throughout the framework seems to be a drag.  And what for? 
> Most people I know working with SVN don't even notice the eol style of the
> files.  Why should "deviations from the SVN native property" be considered
> a bug?  As a matter of principle?  I don't see a good reason why this
> should be an issue.

Because it's just nice ... and it is not a drag if SVN is configured
properly:

      http://www.mediawiki.org/wiki/Subversion/auto-props
        http://svnbook.red-bean.com/en/1.1/ch07.html

Cheers,
Fritz

-- 
Oetiker+Partner AG              tel: +41 62 775 99 03 (direct)
Fritz Zaucker                        +41 62 775 99 00 (switch board)
Aarweg 15                            +41 79 675 06 30 (mobile)
CH-4600 Olten                   fax: +41 62 775 99 05
Schweiz                         web: www.oetiker.ch

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to