On Friday 11 April 2008, Thilo Goetz wrote: > Daniel Kulp wrote: > > On Friday 11 April 2008, Thilo Goetz wrote: > >> For the java code we could set it to native. We just never > >> felt the need. Since we need to be careful with our test > >> files, we don't follow the automatic eol-style client setup > >> as recommended. AFAIK, all UIMA developers use Eclipse > >> for their development, and Eclipse doesn't care about > >> eol style (or not that I noticed anyway). > > > > I just want to say that this is a fairly short sighted view. > > CURRENTLY, all your developers use Eclipse, but if eol-style is not > > set properly on the files, it makes it much harder for other people > > that don't use eclipse to jump in and look at code and help. For > > example, without eol-style, a unix committed file loaded into > > notepad ends up all on one line. (not that anyone in their right > > mind would use notepad) It's > > That's a pretty hypothetical scenario. What editors that a programmer > would use are there on windows that don't handle unix eol chars?
Um... well. If I just need to make a real quick edit (like fix a typo in a string), I may startup anything that starts up real quick, like notepad. Eclipse takes too long. Even on Linux, I use eclipse for most stuff, but if I need to make a quick pom edit or fix a checkstyle error after cruisecontrol emails me a build failure or something, I'll just use vim or something. In anycase, there are a bunch of editors on windows that by default will create files with DOS eol style. I think even eclipse might. If you edit an EXISTING file that is unix, they keep it that way, but creating a new file defaults ot DOS style. If a Unix person using an older version of emacs or vim or something loads that file, they see ^M things all over the place. > You > call it short-sighted, I call it on-demand. If somebody comes along > and says I would like to help with UIMA but I can't because of your > stupid unix eol settings, then we'll certainly reconsider. In the > mean time, we're just saving ourselves some trouble. The main issue is that adding the svn:eol-style CAN be hugely disruptive later. If a file has "mixed" styles (some lines unix, some lines windows), you have to fix it. Which can create HUGE diffs and disrupts history, branch merges, etc... Getting it setup properly at the start prevents a large amount of pain later. Example: in general, the cxf devs are pretty good about it. (I used to run a script once a month or so to double check, but haven't in a while). sebb's script for cxf still resulted in a commit email broken into about 10 parts. The larger a project gets, the harder and more painful it is to fix later. In anycase, not a concern for the release vote, but IMO, something that should be STRONGLY considered. Dan > But I certainly get your point. I recently offered to help on a > project, but decided not to when the developers refused to make a > small change that would have allowed me to work in Eclipse. > > > probably not in the projects best interest to intentional exclude > > folks by making it harder for them to look at the code. Thus, you > > then only attract the folks that use eclipse making it > > self-fullfilling that all the developers use eclipse. > > I agree with you in principle, see above. Just not sure this > is really a concern. > > --Thilo > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
