[Python-Dev] Mercurial, linefeeds, and Visual Studio

[Paul Moore]

2009/6/6 Mark Hammond <skippy.hammond at gmail.com>:
> Paul Moore wrote:
>>
>> 2009/6/5 Nick Coghlan <ncoghlan at gmail.com>:
>>>
>>> Dirkjan Ochtman wrote:
>>>>>
>>>>> Essentially, pcbuild.sln is a binary file, and should be treated as
>>>>> such. Maybe it's an error in the Subversion setup that it's treated as
>>>>> text at all...
>>>>
>>>> Yes, it certainly seems that way.
>>>
>>> Except it isn't a binary file - it's a text file with CRLF line endings.
>>> Why would we throw away the chance to get meaningful diffs when
>>> Subversion can easily get the line endings correct?
>>
>> Fair point - I hadn't thought of it in that context. I wonder if
>> Mercurial can treat it as a specialised form of binary file with
>> custom diff/merge behaviour (which just happens to be "treat as
>> text")? Of course, if that also requires client-side configuration,
>> it's no better solution than win32text.
>>
>> I've a feeling I've seen discussions of versioned metadata (things
>> like file properties) in Mercurial at some point in the past, but my
>> Google skills are failing me at the moment...
>
> I've looked into this recently.  IIUC:
>
> * There has been some limited support expressed for having win32text look in
> a normal versioned file for hints about the current repo.
>
> * Once concern here was the fact that such config files are somewhat
> 'untrusted', but the hg config parsing code has recently been reimplemented
> to support the concept of 'trusted' versus 'untrusted' options.  I'm not
> sure what this means in practice though.
>
> * There isn't currently much activity on win32text.  None of the core hg
> devs seem to use Windows, so while they are receptive to Windows patches, it
> might be necessary to be quite noisy to get attention.
>
> I recently submitted some changes to the filtering for Windows which were
> accepted without any angst, and the ability to use a versioned file for
> per-repo rules is something I'd like too.  I believe that if a few Windows
> users got together and agreed on both semantics and implementation we could
> get such an enhancement landed in the core of hg...

I'm willing to help on this, but I don't personally use win32text (my
approach is to have all files always in Unix line-ending format, which
every tool I use handles fine). So take any design suggestions I might
make with a pinch of salt :-)

Paul.