2009/8/5 "Martin v. Löwis" <mar...@v.loewis.de>: > My personal favorite outcome would be this: > - most files have svn's "native" eol style; they get stored in LF > in the repository; the hook will convert them on Windows, and check > on Unix. > - some files have "windows" eol style; they get stored in CRLF. > The hook will not convert, but only check. > - not sure whether some files need to be declared as "unix" eol style. > - some files are "binary"; they get stored as-is - the hook will > do nothing. > > 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, it seems to me that this proposal also means that the hook would be 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). 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). 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). Paul. _______________________________________________ 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
