On 5/08/2009 8:04 PM, Paul Moore wrote:
2009/8/5 "Martin v. Löwis"<mar...@v.loewis.de>:
With such a setup, using the hook would be truly optional on Unix,
as it only ever checks and never converts. So if you manage to mess
up, and don't have the hook installed on Unix, you lose when trying
to push. That will teach you to be more careful in the future, or
to install the hook (which hopefully becomes built into Mercurial at
some point).
Given that my preference is to use Unix-style EOL for "text" files on
Windows, as every text editor I use (barring notepad!) understands LF
format,
Most tools that I use will tend to not mix EOL styles in a single file,
but will tend to create \r\n line endings for new files I create. Most
hg repos I come across don't have mixed line endings within individual
files, so I can only guess these files were accidentally introduced in
the same way (and indeed I have personally done this.) I'm hoping to be
part of the solution instead of part of the problem :)
> it seems to me that this proposal also means that the hook
would be optional for me.
Technically it would be optional for everyone, of course. However, the
solution should be such that everyone, regardless of personal
preference, is willing to take the hit.
For example, if the repo is converted using \r\n line endings natively,
then Windows users would need to take no action either and puts the onus
back on you (given your stated preferences) to configure the tool
appropriately. I assume you would have no objection to that and would
be happy to make that tool optional for me?
That suits me fine - I'd prefer to avoid
having hooks that are required for Python checkouts, as that means I
have to remember to configure them on each clone (IIUC).
Configuring on each clone would certainly be sub-optimal, so the
proposal is this configuration be stored in a versioned file in the repo.
Of course, this implies that your proposal only requires any action by
the user in the case of Windows users whose text editing tools insist
on CRLF format text files (sources, etc). Is that really a large group
of developers? (I honestly don't know).
It applies to all files that aren't "native" EOL style - there are just
less of them regularly modified than those that are so marked.
I suspect that there is something missing from your proposal, as if
this were the case, then the problem appears to be limited to a very
small group of developers. Maybe it's Visual Studio that insists on
CRLF for source files? (I don't know, as I don't use the VS editor).
If that's the case, then maybe a VS hook would be an alternative
approach? (I can't imagine such a hook would be an *easier* approach,
I only mention it because it makes it clearer where the issue lies).
I must concede that Windows developers are the minority here - but
assuming we want a level playing field, I don't see how that changes the
underlying issue...
Cheers,
Mark
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
