line endings redux (was: 0.15 is)

[John Whitley]

Daniel Parks wrote:
> I want to point out an alternate way to implement this: files are  
> committed as they are now, but are transformed when they're  
> accessed in the repository. In other words, files are normalized on  
> read, instead of write. This could be used for keywords (e.g. $Id 
> $), too.

My biggest concern with this approach is that it doesn't seem to  
adequately control what goes into the repository.  This leaves open  
the problem (plague!) of bad EOL handling in developers' tools  
generating bogus conflicts when merging code.  This problem is  
perhaps more obvious with Bazaar, since merging is such a natural way  
of working[1].  Also, the spec has the following scenario as well:  
some ill-behaved tools die flaming death if the input has incorrect line
endings.

That or else it seems that the bar for a correct implementation  
gating output instead of input into the VCS is much harder to reach.   
(beg pardon for my guessing wildly at bzrlib internals above..  
corrections appreciated.)

> I imagine this would make annotation harder, but it is very safe.

Safety is important, but I'd prefer other solutions if that safety  
comes at the cost of proper EOL management.  In any event, the  
defaults can be safe, i.e. have the default EOL filter be NOP -- the  
same handling as it is today.

An idea I've been tossing around is to use priority-ordered EOL  
descriptions.  Something like:

   # binary patterns
   *.png: binary
   *.jpg: binary
   *.jpeg: binary
    # text patterns
   ./install/*: CRLF
   *: LF

The first pattern that matches, wins.  Failing that (and it may well  
fail, for I haven't had any caffeine yet... >.<  ), an explicit  
section for binary patterns that is checked before other patterns  
might do the trick.

-- John

[1] Anecdote from the past week: I have three branches for a current
     project: an upstream tracking branch, upstream + patches to be  
submitted
     back, upstream + patches + local-only mods.

     My working model is to make changes in the upstream+patches  
branch whenever
     possible, then merge those changes into my upstream+patches 
+local branch...
     Bazaar makes this a snap.  However, I ran into bogus conflicts  
generated
     because of a bug in an editor with otherwise good EOL handling.   
The
     conflicting file was mostly ASCII with a couple of comments in  
Shift-JIS
     and DOS line endings.  When this editor recognizes SJIS  
encoding, turns out
     that it Unix-ifies the line endings on save.  Plain ASCII files  
in the same
     tree were unaffected by this problem...