On Thu, Jun 4, 2009 at 3:49 PM, R. David Murray <rdmurray@bitdance.com> wrote:

The above statement seems like a really odd design choice, with the potential for causing considerable developer coordination headaches.

Any Mercurial boffins want to talk about how this works in practice?

I'm guessing that's just because it uses Mercurial's built-in configuration file chain (.hg/hgrc, ~/.hgrc and /etc/mercurial/hgrc). Those aren't transmitted with repositories because they can contain potentially security-sensitive information (like triggers for executing interesting hooks and information on what users to trust). It would certainly be possible to write a modified win32text-like extension that takes its cues from a versioned file (like the .hgtags and .hgsigs files currently supported). I'm not sure why the original author didn't go that way, though. Cheers, Dirkjan

2009/6/4 Dirkjan Ochtman <dirkjan@ochtman.nl>:

On Thu, Jun 4, 2009 at 3:02 PM, Jason R. Coombs <jaraco@jaraco.com> wrote:

...

I wanted to share this with the community in case anyone else runs into this issue.  Also, if there's a recommended procedure for addressing this issue (and others that might arise due to non-native line endings), I'd be interested to hear it.

Mercurial comes with a win32text extension that helps resolve issues like these. It allows you to specify in the .hg/hgrc that .sln files should always be expanded to CRLF.

Silly question, but given that Mercurial itself does *no* conversion, and CRLF is the only valid form for that file, why shouldn't the file be checked into the repository with CRLF endings, and that's the end of it (apart from misconfigured win32text setups on the client)? Ideally, the history should be imported with CRLF throughout, which is a task for the migration process. If that's too hard because of limitations in the available conversion tools, then maybe the limitation has to be accepted that pre-conversion copies of the file have incorrect line endings and a manual fiox is committed right after the switchover. Doesn't help the current Mercurial mirrors, of course, but at least this report alerts us to a consideration for the final switchover. 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... Paul.

On Thu, Jun 4, 2009 at 4:20 PM, Paul Moore <p.f.moore@gmail.com> wrote:

Silly question, but given that Mercurial itself does *no* conversion, and CRLF is the only valid form for that file, why shouldn't the file be checked into the repository with CRLF endings, and that's the end of it (apart from misconfigured win32text setups on the client)?

That's certainly a valid setup, and I wasn't suggesting otherwise. I have no experience with .sln files, and I haven't really used win32text either; I was just commenting on the general facilities of Mercurial wrt these kinds of issues.

Ideally, the history should be imported with CRLF throughout, which is a task for the migration process. If that's too hard because of limitations in the available conversion tools, then maybe the limitation has to be accepted that pre-conversion copies of the file have incorrect line endings and a manual fiox is committed right after the switchover.

Importing it with CRLF throughout would certainly be possible. I'll add a section to my draft PEP.

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. Cheers, Dirkjan

2009/6/5 Nick Coghlan <ncoghlan@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... Paul.

2009/6/6 Mark Hammond <skippy.hammond@gmail.com>:

Paul Moore wrote:

...

2009/6/5 Nick Coghlan <ncoghlan@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.