--[SPAM]--Re: eolext LF CRLF surprises.

[Jouni Airaksinen]

Frankly I'd prefer if Mercurial would know if the eol has to be used and 
enables it automatically if it's set in the repository (ie. make it 
default extension). Always the hassle here with these user specific 
settings and occasionally we've ended up with mixed eols in files. 
Especially the keyring extension settings seem to be problematic... but 
that's different issue.



From:   Tom Udale <tom at ionoptix.com>
To:     Martin Geisler <mg at aragost.com>
Cc:     mercurial at selenic.com
Date:   29.08.2011 16.07
Subject:        --[SPAM]--Re: eolext LF CRLF surprises.
Sent by:        mercurial-bounces at selenic.com



Hi Martin,

> 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.

Ahh, so the repository format is kind of the "default" answer in the 
event someone updates without the eol extension enabled.  So you can 
decide for yourself, "Ok, I think most people using this are running 
*nix, so I will save things in the repo to be correct for those users 
should they not enable eol."

I could not figure out why anyone cared about the repo format _unless_ 
they were turning on eol after the files are already in the repo.  But 
now it makes more sense.




> 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]
>
>
> If I understand you correctly, then the N format is fixed for all files?

Not quite. N simply means "Native".  There is a system to the 
specifiers.  The left side is the repo format and the right side is the 
working directory format.  Thus

N-LF means "use Native in the repo and LF in the working".

N-N would mean Native in the repo and Native in the working which of 
course is the same as the current Native specifier.  Thus N-N is the 
same as the current "Native" as I tried to indicate in the []s above.

So basically I added 6 specifiers to allow the eol extension to cover 
all 9 possible combinations of the set [Native, LF, CRLF].

Had I been starting from scratch, I would have made LF, and CRLF mean 
Native-LF and Native-CRLF so that for a typical case of starting with an 
empty repo that has eol turned on from the beginning, you would just 
specify the repo Native format as whatever and you would use LF, CRLF 
and Native to indicate the working directory format (assuming of course 
it is understood by everyone to turn on eol).

Then you would only need the odd-ball LF-N, etc specifiers to deal with 
"legacy" repos.

But LF and CRLF already have a different meaning.



> 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.

Yes, that is exactly what I was going for.  Indeed I went for

**.txt = whatever-to-whatever

By supporting all 9 combinations, it is always possible to turn on eol 
and get exactly the working directory you want with zero collateral 
damage in terms of fix-up commits.

You can change the working directory format at any time and avoid 
fix-ups.  Thus if you realize some time down the road you actually 
should have made a file be CRLF instead of native (for example you are 
moving a windows code base to be cross platform with linux) if is as 
simple as changing the .hgeol.  No fix-ups needed.


> You should publish it somewhere, for example on Bitbucket.

Ok, I will clean it up a little bit and look into this Bitbucket business.

Best regards,

Tom

_______________________________________________
Mercurial mailing list
Mercurial at selenic.com
http://selenic.com/mailman/listinfo/mercurial

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20110830/fb560be0/attachment-0002.html>