my strategy on implementing line-endings (eol) support

[Robert Collins]

I realise I'm replying quite late to this thread. I think its great that
you are working on eol support. The squid windows developers use VS and
are crying out for this.

In terms of code in bzrlib, we did discuss eol support at the London
sprint (I really wish you had been able to attend).

http://bazaar-vcs.org/SprintLondonMarch08/Brainstorms#head-f6668b591465639502e563d4321d1a28fd7f0b10 is the notes from the sprint.

The key elements (not all are in the notes :[) are:
 - in memory files will always have canonical line endings. The line
ending conversion will be hidden behind the working tree barrier.
 - We couldn't decide on how to sort out the numerous issues related to
historical control of eol conversion, so we proposed that in the first
implementation there would be nothing in the historical database to
control line endings. We'd just have a config setting to set eol for a
given path/file type/regex. Once we have solid user feedback we can
extend this to historical operations. Doing this avoids having to deal
with merging different eol options for a given file, for instance.
 - the sha1 stored in the dirstate cache should be that of the
canonicalised file content
 - users that share working tree across operating systems *and* use eol
feature, get to keep both pieces.
 - we need a new workingtree format to enable this feature

I suspect you're doing quite a lot more than this, and would like to
suggest that getting the very core bit - the abstraction for working
tree and some methods to call to determine EOL setting inside the tree
for each file into bzr itself would help create a smaller more
reviewable patch.

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080414/8715e0b2/attachment.pgp