incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: UIMA release - lots of missing SVN eol-style property settings
Date Fri, 11 Apr 2008 14:52:42 GMT
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.


> 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:
> For additional commands, e-mail:

J. Daniel Kulp
Principal Engineer, IONA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message