my strategy on implementing line-endings (eol) support

Mark Hammond mhammond at skippinet.com.au
Thu Apr 3 01:38:30 BST 2008


> > | 3) text files with native/LF/CRLF/CR line-endings
> >  Actually, I've never understood (3) - which is also apparently 
> >  what subversion does.
> >  To my mind, a text file either has EOL left alone (ie, "exact") or
> >  has EOL style set to native (where line ends are transformed).
 
> At least one case comes to mind - A build process, executed on windows
> and  containing *nix shell scripts in the distribution (and possibly
> edited by devs on either platform), needs to enforce shell scripts as
> LF not CRLF or the distribution will be incorrect.
> 
> So the VCS protects the distribution by ensuring that, at commit, EOLs
> are normalises and checks out to LF regardless of platform.

Thanks for the clarification, but I'm still a little confused.  I don't see
why this is any different to the answer you just gave to Ian:

> Files with no EOL conversion rules will store exactly what you commit.

So just store these scripts with no EOL conversion (although in this
specific case, "native" would seem better, so users could edit the scripts
on Windows Notepad and still run then on  *nix)

It seems to me that accidently changing the *stored* EOL style on the build
scripts is no worse than accidently changing it on any other text file -
indeed, the build script may be preferred as the error can be seen earlier
as the build breaks :)

ISTM that we actually have 2 partly related issues here:

1) a flag to allow EOL transformations be applied to a file at checkout and
checkin.  It seems "none" and "native" are the only real use cases here.
2) a desire to prevent *any* text file from "accidently" having the EOL
style changed in the repository (ie, after any "native" transformations are
applied) 

ie (2) is true for all text files, regardless of how EOLs are transformed on
the platform.  It seems like 2 different options: "how should they be
transformed natively" and "what EOL style should BZR enforce before allowing
a repo change" (where the implementation of the first will look at the
setting for the second)

But I'm already way out of my depth...

Cheers,

Mark




More information about the bazaar mailing list