my strategy on implementing line-endings (eol) support

[Alexander Belchenko]

Alexander Belchenko пишет:
 > This is exactly my strategy on eol support:
 >
 > a) Internally bzr stores files of type 3 with LF-only eol
 > b) When file is created on disk bzr will use file property called 'eol'
 > to determine
 >   what kind of eol user needs
 > c) status and diff operations should ignore eol, and treat them as LF
 > d) commit convert all kind of eol to LF and store file with LF eol in
 > repository.

a-d is actually implemented (for WT4), but I forgot about

e) merge

Real fun is starting now. I think my branch is ready to start dogfooding
and I only need to figure out strategy on merging content with eol properties
in action. Even without sane merge strategy it should never break the history.

My best guess so far is I need to provide 3-way merger for file properties
and hook it into Merge3 algorithm. So every time when new modified file
will be ready to go on disk I need to have merged value of eol property.

I'm naively thought that merging file properties will be enough to have
as regular file merge, but I was obviously wrong. I need to implement
safe merge-3 algorithm that does not produce conflicts at all to use it
for merge 'eol' property. Something like this: if eol.THIS is different
from eol.BASE, then it always win. Otherwise we use eol.OTHER.

PS: I think I understand why hg does not have built-in merge algorithm.
It's very complex and very important piece of VCS.
And it seems better to don't implement it at all then implement it wrong. :-)