[Python-Dev] Mercurial migration: progress report (PEP 385)

Dirkjan Ochtman dirkjan at ochtman.nl
Fri Jul 3 13:28:02 CEST 2009


On Fri, Jul 3, 2009 at 01:01, Mark Hammond<skippy.hammond at gmail.com> wrote:
> Although this has come up in the past, I don't recall a resolution.
>
> What is your plan to handle svn:eol-style?  We have some files in the tree
> which need that support and it isn't clear to me how that would work with
> the existing win32text extension provided with current mercurial releases.
>  (I've an outstanding patch to hg which should address some of these issues,
> but without the 'rules' being versioned I fear that would still fall short.)

What files would need what? Are there any files that really need to be
\r\n on Windows and \n on Unix (and possibly \r on Mac)? I remember
one file was discussed separately, but I think the outcome there was
that it could just always be \r\n (since it wasn't used at all on
non-Windows platforms). Anyway, knowing specific requirements (or
where to find them) would help here.

> Even more generally, how will you suggest Windows users work?  Will local
> files, in general, have windows line endings or unix?  If the latter, will
> there be hooks in-place to prevent editors on Windows 'accidently' mixing
> eol styles?  If so, this cycles back to the first question - how would we
> know which files get treated that way?

There will be a server-side hook to check whitespace. People will also
be able to install it for commit-time.

I think just using \n by default everywhere is a good default (though
I almost always use Windows client machine, I do all nearly all of my
development through a terminal on several Linux boxen), except where
it isn't. People who want to use can set up the win32text stuff to get
\r\n on Windows if they feel they need that -- we can provide
information about that in the dev FAQ (although it would be nice if
someone else who was more familiar with it -- like yourself! -- would
write it).

Cheers,

Dirkjan


More information about the Python-Dev mailing list