Hi Thomas, although I agree with you in general ...
On Fri, 9 Apr 2010, thron7 wrote: > My take on this issue is: There are basically two types of qooxdoo users: > > - SDK users; they should simply use the SDK "as is" and treat it as a > black box. All involved tools that process the files of the SDK (i.e > browsers and Python) are effectively ignorant about the eol style. And > so should be the user :). I don't expect them to look at framework code. ... I think even SDK users can/should use the framework code both as additional documentation and as example/howto code "properly" with Qooxdoo. 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). It might (!) be useful to provide two different SDKs, one with Unix and one with Windows kind of eol style. > - SVN users; these are sort of "power users", and might look at > framework code. But then I would expect them to have "power tools" at > hand, namely an editor that again hides the various line endings :). 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). > If you are an SDK user but need to have the framework code with a certain > eol style (e.g. because you happen to add the SDK to your own project > repository), you're on your own. If you change the code, you also take > responsibility for the result (and we might not be able to help if you run > into trouble). > > How you treat your project code, however, is at your sole discretion, and > 'generate.py fix' might be used to achieve what you want. Which is of course useful for getting consistent source files, especially for people working in a mixed-OS environment. Cheers, Fritz > T. > > On 04/01/2010 05:10 PM, Peter Schneider wrote: >> Hi Derrell, >> >> sorry, but I have to come back to this "issue". >> >> For what my experiences are, the subversion properties are version'ed. >> So this means the property (in our case "eol-style") has to be set to >> "native" >> by the one that is committing/adding the file. >> >> Example: >> ======== >> When you take a look at the "qx/bom/element/Dimension.js"[1] file for example >> the property is set. This file gets DOS line-endings! >> While "qx/bom/element/Decoration.js"[2] for example does not have that >> property >> set and will get UNIX line-endings...at least on my machine ;) >> >> I am not sure if you can set a 'auto-property' for the "svn checkout" >> operations. I'm only aware of the "svn add" and "svn import" automatic >> property >> setting feature. >> >> By the way, I checked the 'checkout' both with TortoiseSVN and with the >> current >> command line client, both checkouts resulted in having files with mixed >> line-endings :( >> >> If you have a tip for me how to fix this on my (working-copy) side, I would >> be >> happy if you would share that info ;) >> On the other hand, it might be a good idea to add the "svn:eol-style=native" >> property to all *.js files and commit that change to the repository. >> >> Regards, and happy easter holidays >> Peter >> >> >> [1]"https://qooxdoo.svn.sourceforge.net/svnroot/qooxdoo/trunk/qooxdoo/framework/source/class/qx/bom/element/Dimension.js"; >> [2]"https://qooxdoo.svn.sourceforge.net/svnroot/qooxdoo/trunk/qooxdoo/framework/source/class/qx/bom/element/Decoration.js"; >> >> >> >> -------- Original -------- >> From: Derrell Lipman >> Date: 30.03.2010 17:14 >> >>> On Tue, Mar 30, 2010 at 10:35, Daniel Wagner <[email protected]> wrote: >>> >>>> Hi Peter, >>>> >>>> I asked some of the other core devs but nobody knew a reason other than >>>> "we had to decide one way or the other so we just went with Unix-style >>>> line endings". It's just a convention, like the "two spaces for >>>> indentation" rule. >>>> >>> >>> Actually, the line ending isn't something that anyone should have to worry >>> about. svn handles line endings for various operating systems automatically >>> if you let it. Internally it will store line endings as a canonicalized LF >>> but upon checkout, convert to the line endings that are appropriate to the >>> OS being used for the checkout (and back again, upon commit). This is >>> enabled by setting the property svn:eol-style to "native". See the >>> "eol-style" section in the svn book, here: >>> >>> http://svnbook.red-bean.com/en/1.1/ch07s02.html >>> >>> Derrell >> >> ------------------------------------------------------------------------------ >> 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 >> >> > > ------------------------------------------------------------------------------ > 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 > > -- 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
