eolext LF CRLF surprises.

[Martin Geisler]

Tom Udale <tom at ionoptix.com> writes:

Hi Tom,


> One of the things that very much surprised me about eol was the
> behavior of LF and CRLF. I assumed that they controlled only the
> format in the working directory, not the format in the repository. So
> it took me indeed quite a while to figure out that LF and CRLF force
> the same endings both inside and outside the repo.

Yeah... that seems to confuse people to no end :-(

> This is basically an alias for BIN - that is, no translation - with
> the single exception that you can somewhat painfully force a change in
> line endings if you need to.  The painful aspect is that you must
> commit because any actual change will the file look modified to the
> repo.

That was meant to be a feature :-) The idea is that a project decides
that '*.txt = CRLF' and then it doesn't matter if a guy on Linux creates
a LF formatted text file: it will be saved with the correct format in
the repository.

The need for a repository format is caused by the fact that people might
not use the extension. So unlike Subversion (which I looked at when I
wrote the extension), you might actually see the repository format.

> The reality is that you don't really care what the internal
> representation of the file is _unless_ it is different from the
> repository canonical format when eol is enabled.  And then you only
> care for the practical consideration of preventing spurious commits,
> not because of some deep seated concern for the repo internals.
>
> Another practical need is for the working directory to be in some form
> or another based on the unix/DOSness of the host computer.
>
> So to maximize the utility of eol in the face of differing paths to
> your hg repo (which will result in various states of files in the
> repo) and in the  face of differing working directory needs, you want
> to be able to specify both sides of the equation for each file, the
> repo and the working directory.
>
> You specify the repo to side to contend with files already checked in
> which are not in the canonical format, and you specify the working
> directory side as needed for the host system.
>
> It turns out that you need only about one hurricane's worth of time to
> implement this.  Today I managed to get hg building from sources and
> then added 6 new specifiers that along with the three existing ones
> fill out all combinations of native, LF and CRLF.

Heh, thanks Irene :-)

> I chose them as follows (decode as repo-working where N means "native"):
>
> N-LF
> N-CRLF
> [existing Native is the same as N-N]
>
> LF-N
> LF-CRLF
> [existing LF is the same as LF-LF]
>
> CRLF-N
> CRLF-LF
> [existing CRLF is the same as CRLF-CRLF]

> The envisioned use is as follows:
>
> if your hg repo is completely homogenous in text file eols, you set up
> your repo to be canonical in that eol and then pick _always_ one of
> the N- variants N-LF, N-CRLF, or Native to get the files into your
> working directory as needed.  This way you don't have to concern
> yourself with whatever the repo format is and you can still maintain
> repo homogeneity.

If I understand you correctly, then the N format is fixed for all files?
Several users have asked for a format that would let them say

  **.txt = whatever-to-native

meaning that .txt files will be written to the working copy in the OS
native newline format and saved back to the repository in whatever
format they already have. That would be like magic: you can start using
the extension and you wont get the big fixup commits that people
currently have to do.

> The changes needed to add new specifications and converters are,
> thanks to the design of eol, trivial (assuming I am not missing some
> corner cases).  It appears you don't even need to understand how the
> filters are ultimately called :)
>
> If anyone is interested, I would be happy to send them along.

You should publish it somewhere, for example on Bitbucket.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/