End of line characters in bzr

[John Whitley]

John Arbash Meinel wrote:
> At this point, most editors can handle files in whatever line endings
> they started with.

While I agree that bzr's behavior is better than CVS' (on almost any  
point I can think of ;), the ability to enforce line-ending policy is  
really important.  Believe me, there are plenty of tools that are  
more than happy to bork line-endings in a mixed environment.  Most  
often, we end up with files with mixed endings.  For example, MS  
Visual Studio 7 is a big offender: any autotext IDE functionality  
will add Windows line-endings without regard to the file's convention.

> The page Alexander linked to has most of the discussion. I'm pretty  
> sure
> Martin thinks it is something to have. But it isn't a priority ATM.
> Leaving things alone is a pretty good default. But if someone  
> implements
> a clean implementation that handles that we are using sha1 sums, so we
> need to filter whenever we read and write... (You may need to keep  
> 2 sha
> sums, one for the current on-disk sum, and 1 for the after filtered  
> sum.
> Though you may only need the after-filtered)

I've always thought of this as the line-ending behavior as a property  
of the file.    (or a pattern-inherited property, more usefully).   
The filtered/corrected version is the only one that matters.

I was under the impression that this support hinged on per-file  
properties landing, which hasn't happened to my knowledge.  (and I  
haven't had the bandwidth to pitch in and help...  :P  ).  That  
support would also give Bazaar a natural place to persist things like  
which files are binary, etc.

I must admit that I'm not clear what the best workflow is when an out- 
of-whack file is encountered.  If the filter encounters files with  
endings differing from the property setting, it should probably abort  
any commits and offer to correct the on-disk files.  That way the  
user can check the filter's correctness before committing.

-- John