line endings redux (was: 0.15 is)
whitley at acm.org
Tue Mar 6 17:49:20 GMT 2007
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. Also, the spec has the following scenario as well:
some ill-behaved tools die flaming death if the input has incorrect line
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..
> 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
# text patterns
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.
 Anecdote from the past week: I have three branches for a current
project: an upstream tracking branch, upstream + patches to be
back, upstream + patches + local-only mods.
My working model is to make changes in the upstream+patches
possible, then merge those changes into my upstream+patches
Bazaar makes this a snap. However, I ran into bogus conflicts
because of a bug in an editor with otherwise good EOL handling.
conflicting file was mostly ASCII with a couple of comments in
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...
More information about the bazaar