Re: Compatible with Microsoft Office and Internet Explorer
On Wed, Jan 25, 2012 at 7:26 AM, Ryan Schmidt subversion-20...@ryandesign.com wrote: I apologize in advance if the below reply is snarky, but I'm a little tired of this particular topic; it has been talked to death already long ago. On Jan 24, 2012, at 19:24, Nico Kadel-Garcia wrote: The big booby trap I notice with all Windows/Subversion use is the understandable desire to use native end-of-line characters to swap text files gracefully between Linux, Windows, and MacOS. Don't do that: it can bite you *VERY* hard if you access the same network filesystem, such as a CIFS share, from each of those operating systems or with CygWin on Windows. Nico, I know you have a strong opinion about the svn:eol-style property, specifically that it should never be used, and you love voicing this opinion in as many threads on this mailing list as possible, regardless of whether it is relevant to the thread or not. I'll respond yet again, in a different form that is perhaps more effective in explaining my views: There are several kinds of files you might have in your repository: 1. Binary files, such as images, sounds, videos, compiled programs, compressed archives, spreadsheets, presentations, some word processing documents, etc. Setting svn:eol-style to any value on these files would likely corrupt them, so svn:eol-style should not be set on these kinds of files. 2. Text files where you want some lines to have LF line endings and other lines to have CRLF line endings. I hope there is agreement that nobody ever wants these kinds of files, yet this is exactly the kind of file you will get if you do not set svn:eol-style, and you have several different people editing the files, on different platforms, using different editors. That was my actual experience at the last company I worked for. The specific problem editor in our case was UltraEdit on Windows, which happened to be the editor my company had paid for, so it was the one most of our developers were using. Unless you set four separate settings in its options window to four specific non-default values (which you had to wade through a hundred other options to find), it had very strange ideas about how line endings should be handled. (It preserved the existing line ending style for lines you did not edit, but used CRLF line endings for any lines you did edit.) Therefore, I recommend you always set the svn:eol-style property of text files to some value. What value? Read on. 3. Text files where you want line endings to always be LF regardless of platform. In this case, set svn:eol-style to LF. The Subversion client transforms the file's line endings to LF before commit, and when you check out, gives you a file with LF line endings. If you or your broken editor somehow transform some of the file's lines to CRLF line ending, the Subversion client* will prevent you from committing that broken text file back to the repository until you fix the broken line endings so that they are consistent. Hooray. Note that there is no problem if you or your editor convert the *entire* file to a different line ending style before committing; Subversion will seamlessly convert it back to the line ending style indicated in the svn:eol-style property. 4. Text files where you want line endings to always be CRLF regardless of platform. In this case, set svn:eol-style to CRLF. In the same spirit as (3) above, the Subversion client* will ensure the file in the repository has only CRLF line endings. 5. Text files where you want line endings to be CRLF if checked out with a native Windows client, and LF otherwise. In this case, set svn:eol-style to native. Subversion will store the file in the repository with LF line endings. When checking out on native Windows, it will convert the line endings from LF to CRLF, and on commit, will convert back to LF. On non-Windows systems (including cygwin, I believe), the files will be checked out and committed in their unconverted state using LF line endings. Yes, you will run into problems if you share a working copy between native Windows and non-Windows (including cygwin IIRC) environments. Rather than state that svn:eol-style should therefore never be used, or should never be set to native, you should instead stop sharing working copies. If you cannot give that up, then yes, in your specific unusual case, setting svn:eol-style to native might not be a good idea. Do not however condemn the use of svn:eol-style native for everyone, nor the use of svn:eol-style in general. I manage a repository of web site code. It contains HTML web pages, CSS stylesheets, JavaScript code, Markdown-formatted documentation. On my Mac I prefer these files to have LF line endings, because if I want to use UNIX command line tools on these files, they work best with LF line endings, and GUI editors on OS X default to LF line endings too. I assume Windows
Re: Compatible with Microsoft Office and Internet Explorer
Guten Tag Les Mikesell, am Mittwoch, 25. Januar 2012 um 07:11 schrieben Sie: The fact that text is different on different systems isn't really something you can disagree with. I don't like it any more than you do, but that's just the way it is - something decided back in a different century. That is really no argument as almost any developer tool is able to handle both line endings today. You just have to configure it in your IDE, TextEditor and whatever you use once and for all the team, just like you define any other coding rules and there will be exactly no problem. A lot of things were decided centuries ago and we don't do them anymore. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon.030-2 1001-310 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Compatible with Microsoft Office and Internet Explorer
On 25/01/12 06:26, Ryan Schmidt wrote: I apologize in advance if the below reply is snarky, but I'm a little tired of this particular topic; it has been talked to death already long ago. On Jan 24, 2012, at 19:24, Nico Kadel-Garcia wrote: The big booby trap I notice with all Windows/Subversion use is the understandable desire to use native end-of-line characters to swap text files gracefully between Linux, Windows, and MacOS. Don't do that: it can bite you *VERY* hard if you access the same network filesystem, such as a CIFS share, from each of those operating systems or with CygWin on Windows. Nico, I know you have a strong opinion about the svn:eol-style property, specifically that it should never be used, and you love voicing this opinion in as many threads on this mailing list as possible, regardless of whether it is relevant to the thread or not. I'll respond yet again, in a different form that is perhaps more effective in explaining my views: There are several kinds of files you might have in your repository: 1. Binary files, such as images, sounds, videos, compiled programs, compressed archives, spreadsheets, presentations, some word processing documents, etc. Setting svn:eol-style to any value on these files would likely corrupt them, so svn:eol-style should not be set on these kinds of files. 2. Text files where you want some lines to have LF line endings and other lines to have CRLF line endings. I hope there is agreement that nobody ever wants these kinds of files, yet this is exactly the kind of file you will get if you do not set svn:eol-style, and you have several different people editing the files, on different platforms, using different editors. That was my actual experience at the last company I worked for. The specific problem editor in our case was UltraEdit on Windows, which happened to be the editor my company had paid for, so it was the one most of our developers were using. Unless you set four separate settings in its options window to four specific non-default values (which you had to wade through a hundred other options to find), it had very strange ideas about how line endings should be handled. (It preserved the existing line ending style for lines you did not edit, but used CRLF line endings for any lines you did edit.) Therefore, I recommend you always set the svn:eol-style property of text files to some value. What value? Read on. 3. Text files where you want line endings to always be LF regardless of platform. In this case, set svn:eol-style to LF. The Subversion client transforms the file's line endings to LF before commit, and when you check out, gives you a file with LF line endings. If you or your broken editor somehow transform some of the file's lines to CRLF line ending, the Subversion client* will prevent you from committing that broken text file back to the repository until you fix the broken line endings so that they are consistent. Hooray. Note that there is no problem if you or your editor convert the *entire* file to a different line ending style before committing; Subversion will seamlessly convert it back to the line ending style indicated in the svn:eol-style property. 4. Text files where you want line endings to always be CRLF regardless of platform. In this case, set svn:eol-style to CRLF. In the same spirit as (3) above, the Subversion client* will ensure the file in the repository has only CRLF line endings. 5. Text files where you want line endings to be CRLF if checked out with a native Windows client, and LF otherwise. In this case, set svn:eol-style to native. Subversion will store the file in the repository with LF line endings. When checking out on native Windows, it will convert the line endings from LF to CRLF, and on commit, will convert back to LF. On non-Windows systems (including cygwin, I believe), the files will be checked out and committed in their unconverted state using LF line endings. Yes, you will run into problems if you share a working copy between native Windows and non-Windows (including cygwin IIRC) environments. Rather than state that svn:eol-style should therefore never be used, or should never be set to native, you should instead stop sharing working copies. If you cannot give that up, then yes, in your specific unusual case, setting svn:eol-style to native might not be a good idea. Do not however condemn the use of svn:eol-style native for everyone, nor the use of svn:eol-style in general. I manage a repository of web site code. It contains HTML web pages, CSS stylesheets, JavaScript code, Markdown-formatted documentation. On my Mac I prefer these files to have LF line endings, because if I want to use UNIX command line tools on these files, they work best with LF line endings, and GUI editors on OS X default to LF line endings too. I assume Windows users would prefer them to have CRLF line endings, because that's what Notepad and probably other Windows
Re: Compatible with Microsoft Office and Internet Explorer
On 1/25/2012 12:51 AM, Thorsten Schöning wrote: Guten Tag Les Mikesell, am Mittwoch, 25. Januar 2012 um 07:11 schrieben Sie: The fact that text is different on different systems isn't really something you can disagree with. I don't like it any more than you do, but that's just the way it is - something decided back in a different century. That is really no argument as almost any developer tool is able to handle both line endings today. You just have to configure it in your IDE, TextEditor and whatever you use once and for all the team, just like you define any other coding rules and there will be exactly no problem. A lot of things were decided centuries ago and we don't do them anymore. Are you going to pay me (and all my clients) to buy those tools for every machine in the known universe? I didn't think so. And what happens when files get mixed line endings? Are you sure that all tools handle them reliably? I use svn:eol-style=native because it works reliably across platforms. Without it I can't always edit text files on client Windows machines - Notepad does not handle bare newlines *at all*. (That alone is a good reason not to copy files from Linux to Windows directly, whether directly or by viewing from a network file system.) -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: Compatible with Microsoft Office and Internet Explorer
2012/1/25 Thorsten Schöning tschoen...@am-soft.de: Guten Tag Les Mikesell, am Mittwoch, 25. Januar 2012 um 07:11 schrieben Sie: The fact that text is different on different systems isn't really something you can disagree with. I don't like it any more than you do, but that's just the way it is - something decided back in a different century. That is really no argument as almost any developer tool is able to handle both line endings today. Highly trained/skilled developers can handle a lot of things that you don't expect in general. You just have to configure it in your IDE, TextEditor and whatever you use once and for all the team, just like you define any other coding rules and there will be exactly no problem. A lot of things were decided centuries ago and we don't do them anymore. Do you have a definitive list of the tools you can expect to work with non-native text lines? Or, if the list is smaller these days, the ones that won't? And what do you do when something else makes a change that suddenly makes the whole file show modifications that you can't see? -- Les Mikesell lesmikes...@gmail.com
RE: Compatible with Microsoft Office and Internet Explorer
From: ANTOINE-PRAVEEN-JANVIER Joseph -EXT [mailto:joseph.antoine-praveen-janvier-...@alstom.com] Sent: Tuesday, January 24, 2012 5:07 AM To: users@subversion.apache.org Subject: Compatible with Microsoft Office and Internet Explorer Importance: High Hello Support Team, We are the users of the Tortoise product and we need to know its compatibility status with Microsoft application. Please let us know if the application is compatible with MS Office 2000, MS Office 2010 and Internet Explorer (version 8). Kindly also let know from which version onwards it is compatible. Product MS office 2000 MS office 2010 IE8 Tortoise Compatible E.g; Use Magnet SVN http://magnetsvn.com/ Compatible E.g; Use Magnet SVN http://magnetsvn.com/ Which kind of Compatibility you need? Do you want to access TSVN through Web? Appreciate your support. Thanks and Regards, Joseph Antoine Praveen Janvier | Workplace project | ALSTOM Compatibility Cell | Office Phone +44 20 709 53688 CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
Re: Compatible with Microsoft Office and Internet Explorer
Guten Tag ANTOINE-PRAVEEN-JANVIER Joseph -EXT, am Dienstag, 24. Januar 2012 um 11:06 schrieben Sie: We are the users of the Tortoise product and we need to know its compatibility status with Microsoft application. TortoiseSVN has it's own mailing list: http://tortoisesvn.net/support.html Please let us know if the application is compatible with MS Office 2000, MS Office 2010 and Internet Explorer (version 8). At least I don't really understand your question, if you're saying that you already use Tortoise, because it's a Windows Explorer integration and as such is rarely used in those programs. Maybe it will help the Tortoise people if you describe the background of your question more detailed, for example if you have any problems or else. Tortoise shouldn't be a problem in your programs at all. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon.030-2 1001-310 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Compatible with Microsoft Office and Internet Explorer
On Tue, Jan 24, 2012 at 5:06 AM, ANTOINE-PRAVEEN-JANVIER Joseph -EXT joseph.antoine-praveen-janvier-...@alstom.com wrote: Hello Support Team, We are the users of the *Tortoise *product and we need to know its compatibility status with Microsoft application. Please let us know if the application is compatible with MS Office 2000, MS Office 2010 and Internet Explorer (version 8). Hi there. This is the *subversion* mailing list, not the tortoisesvn mailing list, you should really ask over there. However, as a professional multi-platform systems admin and decades long integrator of source control, Microsoft operating systems, UNIX, and Linux since it came out, I I can tell you that it's very powerful and very effective. The recent updates to Subversion 1.7.x as its core have vastly improved its NTFS performance for Windows systems, and been all around good. The big booby trap I notice with all Windows/Subversion use is the understandable desire to use native end-of-line characters to swap text files gracefully between Linux, Windows, and MacOS. Don't do that: it can bite you *VERY* hard if you access the same network filesystem, such as a CIFS share, from each of those operating systems or with CygWin on Windows. Kindly also let know from which version onwards it is compatible. Product MS office 2000 MS office 2010 IE8 Tortoise It's kind of a strange question, because they're orthogonal. Subversion works by saving files and a log of their changes. MS Office stores *binary* files, and increasingly complex XML based and incompatible artifices of proprietary incompatibility. So you can save them, and access them, but preserving a list of changes in the document contents that would be effectively reported as differences by Subversion is pretty impossible. Do you understand how Microsoft's workd and Excel documents work, at all? Then you know that the chance of being able to publish an organized and legible set of differences between an older and newer modified document is about the same chance as sneezing up your tongue. It could happen, if you worked at it really hard, but it's not likely. IE of various flavors works just fine to browse Subversion repositories using HTTPS or HTTP access. It works even better with an intervening web interface, such as 'viewvc'. For maintaining website content, the source control system has little to do with making the content compatible with IE of any flavor. Appreciate your support. Thanks and Regards, Joseph Antoine Praveen Janvier | Workplace project | ALSTOM Compatibility Cell | Office Phone +44 20 709 53688 -- CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
Re: Compatible with Microsoft Office and Internet Explorer
What do you do if you're accessing the same filesystem from both Windows and UNIX? What line-ending method do you use for text files, and what do you put for svn:eol-style? Richard - Original Message - From: Nico Kadel-Garcia Sent: 01/25/12 11:24 AM To: ANTOINE-PRAVEEN-JANVIER Joseph -EXT Subject: Re: Compatible with Microsoft Office and Internet Explorer On Tue, Jan 24, 2012 at 5:06 AM, ANTOINE-PRAVEEN-JANVIER Joseph -EXT joseph.antoine-praveen-janvier-...@alstom.com wrote: Hello Support Team, We are the users of the Tortoise product and we need to know its compatibility status with Microsoft application. Please let us know if the application is compatible with MS Office 2000, MS Office 2010 and Internet Explorer (version 8). Hi there. This is the *subversion* mailing list, not the tortoisesvn mailing list, you should really ask over there. However, as a professional multi-platform systems admin and decades long integrator of source control, Microsoft operating systems, UNIX, and Linux since it came out, I I can tell you that it's very powerful and very effective. The recent updates to Subversion 1.7.x as its core have vastly improved its NTFS performance for Windows systems, and been all around good. The big booby trap I notice with all Windows/Subversion use is the understandable desire to use native end-of-line characters to swap text files gracefully between Linux, Windows, and MacOS. Don't do that: it can bite you *VERY* hard if you access the same network filesystem, such as a CIFS share, from each of those operating systems or with CygWin on Windows.
Re: Compatible with Microsoft Office and Internet Explorer
On Tue, Jan 24, 2012 at 8:44 PM, Richard Cavell richardcav...@mail.com wrote: What do you do if you're accessing the same filesystem from both Windows and UNIX? What line-ending method do you use for text files, and what do you put for svn:eol-style? Richard I rely extensively on the default of *no* setting, referred to in Subversion as not setting or blocking the svn:eol property. This treats line endings as effectively binary data, preserved identically no matter which platform you check out files on. If you need to work with Windows line endings for source code on one system, and UNIX line endings for source code on another, that's a locak system problem, not properly a source control problem. I'm afraid I've had real adventures when someone insisted on working with TortoiseSVN with svn:eol set to native, and thenm trying to build perl scripts and Java source code on both Windows and Linux systems in the same home directory. This led to madness - Original Message - From: Nico Kadel-Garcia Sent: 01/25/12 11:24 AM To: ANTOINE-PRAVEEN-JANVIER Joseph -EXT Subject: Re: Compatible with Microsoft Office and Internet Explorer On Tue, Jan 24, 2012 at 5:06 AM, ANTOINE-PRAVEEN-JANVIER Joseph -EXT joseph.antoine-praveen-janvier-...@alstom.com wrote: Hello Support Team, We are the users of the Tortoise product and we need to know its compatibility status with Microsoft application. Please let us know if the application is compatible with MS Office 2000, MS Office 2010 and Internet Explorer (version 8). Hi there. This is the *subversion* mailing list, not the tortoisesvn mailing list, you should really ask over there. However, as a professional multi-platform systems admin and decades long integrator of source control, Microsoft operating systems, UNIX, and Linux since it came out, I I can tell you that it's very powerful and very effective. The recent updates to Subversion 1.7.x as its core have vastly improved its NTFS performance for Windows systems, and been all around good. The big booby trap I notice with all Windows/Subversion use is the understandable desire to use native end-of-line characters to swap text files gracefully between Linux, Windows, and MacOS. Don't do that: it can bite you *VERY* hard if you access the same network filesystem, such as a CIFS share, from each of those operating systems or with CygWin on Windows.
Re: Compatible with Microsoft Office and Internet Explorer
On Tue, Jan 24, 2012 at 8:17 PM, Nico Kadel-Garcia nka...@gmail.com wrote: On Tue, Jan 24, 2012 at 8:44 PM, Richard Cavell richardcav...@mail.com wrote: What do you do if you're accessing the same filesystem from both Windows and UNIX? What line-ending method do you use for text files, and what do you put for svn:eol-style? Richard I rely extensively on the default of *no* setting, referred to in Subversion as not setting or blocking the svn:eol property. This treats line endings as effectively binary data, preserved identically no matter which platform you check out files on. If you need to work with Windows line endings for source code on one system, and UNIX line endings for source code on another, that's a locak system problem, not properly a source control problem. No, it is a transport problem, and if you use a source control system to transport text it should make it text as expected on each client. I'm afraid I've had real adventures when someone insisted on working with TortoiseSVN with svn:eol set to native, and thenm trying to build perl scripts and Java source code on both Windows and Linux systems in the same home directory. This led to madness But the madness comes from not converting to the expected text form. If you bypass that on purpose, do you preprocess every text file before use on each system or restrict access to a small set of tools that might work in spite of this input? -- Les Mikesell lesmikes...@gmail.com
Re: Compatible with Microsoft Office and Internet Explorer
On Tue, Jan 24, 2012 at 9:38 PM, Les Mikesell lesmikes...@gmail.com wrote: On Tue, Jan 24, 2012 at 8:17 PM, Nico Kadel-Garcia nka...@gmail.com wrote: On Tue, Jan 24, 2012 at 8:44 PM, Richard Cavell richardcav...@mail.com wrote: What do you do if you're accessing the same filesystem from both Windows and UNIX? What line-ending method do you use for text files, and what do you put for svn:eol-style? Richard I rely extensively on the default of *no* setting, referred to in Subversion as not setting or blocking the svn:eol property. This treats line endings as effectively binary data, preserved identically no matter which platform you check out files on. If you need to work with Windows line endings for source code on one system, and UNIX line endings for source code on another, that's a locak system problem, not properly a source control problem. No, it is a transport problem, and if you use a source control system to transport text it should make it text as expected on each client. This is one of those cases where I really disagree with this dangerous model. Expecting on the fly translation, by the source control system, of the format of the files leads to very confusing and awkward results, for which I've listed examples. Like expecting the document viewer to automatically translate date formats of enclosed documents, it can get *extremely* confusing. I'm afraid I've had real adventures when someone insisted on working with TortoiseSVN with svn:eol set to native, and thenm trying to build perl scripts and Java source code on both Windows and Linux systems in the same home directory. This led to madness But the madness comes from not converting to the expected text form. If you bypass that on purpose, do you preprocess every text file before use on each system or restrict access to a small set of tools that might work in spite of this input? I respectfully disagreee, with the messed up scars to match. A source repository should be just that, a source repository. The checked out source code that *appears* to work with both the text-based CygWin client or a Linux client, and a Windows client, fails not becuase the compilers or scripting languages can't handle the code, but because the svn:eol has switched the content of the file at checkout time, and the other client has no way to detect that it needs to be switched back on upload. So a file that you check out in Windows, using svn:eol native, will be seen by a CygWin or Linux client as having its EOL modified and will be reported as altered and potentially committed with the line ending changes. Chaos ensues, even round-robin cases where ^H gets added cyclically to the same files on every automated checkin of a build procedure. (Welcome to Java code that is supposed to be cross-platform and automated build procedures with Cruise Control software. Been there, done that, had to replace the repo and put in pre-commit hooks to block the use of svn:eol.
Re: Compatible with Microsoft Office and Internet Explorer
So, in the interests of keeping the Subversion handbook current and reliable, what is the present advice regarding svn:eol-style? Richard - Original Message - From: Nico Kadel-Garcia Sent: 01/25/12 02:57 PM To: Les Mikesell Subject: Re: Compatible with Microsoft Office and Internet Explorer On Tue, Jan 24, 2012 at 9:38 PM, Les Mikesell lesmikes...@gmail.com wrote: On Tue, Jan 24, 2012 at 8:17 PM, Nico Kadel-Garcia nka...@gmail.com wrote: On Tue, Jan 24, 2012 at 8:44 PM, Richard Cavell richardcav...@mail.com wrote: What do you do if you're accessing the same filesystem from both Windows and UNIX? What line-ending method do you use for text files, and what do you put for svn:eol-style? Richard I rely extensively on the default of *no* setting, referred to in Subversion as not setting or blocking the svn:eol property. This treats line endings as effectively binary data, preserved identically no matter which platform you check out files on. If you need to work with Windows line endings for source code on one system, and UNIX line endings for source code on another, that's a locak system problem, not properly a source control problem. No, it is a transport problem, and if you use a source control system to transport text it should make it text as expected on each client. This is one of those cases where I really disagree with this dangerous model. Expecting on the fly translation, by the source control system, of the format of the files leads to very confusing and awkward results, for which I've listed examples. Like expecting the document viewer to automatically translate date formats of enclosed documents, it can get *extremely* confusing. I'm afraid I've had real adventures when someone insisted on working with TortoiseSVN with svn:eol set to native, and thenm trying to build perl scripts and Java source code on both Windows and Linux systems in the same home directory. This led to madness But the madness comes from not converting to the expected text form. If you bypass that on purpose, do you preprocess every text file before use on each system or restrict access to a small set of tools that might work in spite of this input? I respectfull y disagreee, with the messed up scars to match. A source repository should be just that, a source repository. The checked out source code that *appears* to work with both the text-based CygWin client or a Linux client, and a Windows client, fails not becuase the compilers or scripting languages can't handle the code, but because the svn:eol has switched the content of the file at checkout time, and the other client has no way to detect that it needs to be switched back on upload. So a file that you check out in Windows, using svn:eol native, will be seen by a CygWin or Linux client as having its EOL modified and will be reported as altered and potentially committed with the line ending changes. Chaos ensues, even round-robin cases where ^H gets added cyclically to the same files on every automated checkin of a build procedure. (Welcome to Java code that is supposed to be cross-platform and automated build procedures with Cruise Control software. Been there, done that , had to replace the repo and put in pre-commit hooks to block the use of svn:eol.
Re: Compatible with Microsoft Office and Internet Explorer
On Tue, Jan 24, 2012 at 10:57 PM, Nico Kadel-Garcia nka...@gmail.com wrote: If you need to work with Windows line endings for source code on one system, and UNIX line endings for source code on another, that's a locak system problem, not properly a source control problem. No, it is a transport problem, and if you use a source control system to transport text it should make it text as expected on each client. This is one of those cases where I really disagree with this dangerous model. Expecting on the fly translation, by the source control system, of the format of the files leads to very confusing and awkward results, for which I've listed examples. No, your examples were where you deliberately circumvented the conversion in the transport. The fact that text is different on different systems isn't really something you can disagree with. I don't like it any more than you do, but that's just the way it is - something decided back in a different century. I'm afraid I've had real adventures when someone insisted on working with TortoiseSVN with svn:eol set to native, and thenm trying to build perl scripts and Java source code on both Windows and Linux systems in the same home directory. This led to madness But the madness comes from not converting to the expected text form. If you bypass that on purpose, do you preprocess every text file before use on each system or restrict access to a small set of tools that might work in spite of this input? I respectfully disagreee, with the messed up scars to match. No, your scars came from _not_ letting the conversion work correctly. You let different OS's see it without having gone through the appropriate transport. A source repository should be just that, a source repository. Something that handles text needs to handle text in the native OS form. Something that transports text across platforms needs to deliver native text to each. You can't just pretend that text is not different on different platforms even if you wish that were true. The checked out source code that *appears* to work with both the text-based CygWin client or a Linux client, and a Windows client, fails not becuase the compilers or scripting languages can't handle the code, but because the svn:eol has switched the content of the file at checkout time, and the other client has no way to detect that it needs to be switched back on upload. Cygwin is a weird beast. Use it only if you understand and want what it does. So a file that you check out in Windows, using svn:eol native, will be seen by a CygWin or Linux client as having its EOL modified and will be reported as altered and potentially committed with the line ending changes. Of course, if you use a method of getting a text file to a different OS in a way that doesn't perform the needed conversion, it won't work. If it hurts, don't do that. Chaos ensues, even round-robin cases where ^H gets added cyclically to the same files on every automated checkin of a build procedure. (Welcome to Java code that is supposed to be cross-platform and automated build procedures with Cruise Control software. Errr, what? Why would an automated build be checking in/out on the wrong OS? Doesn't that system let each target system do its own checkouts in cross platform builds? I'm pretty sure we have people doing that with Jenkins all the time. Been there, done that, had to replace the repo and put in pre-commit hooks to block the use of svn:eol. But you didn't answer my question above. Many/most tools simply will not work without conversion. Since you don't use the painless approach of having everything done automatically, what do you do instead? Do you always use your own conversion tool before letting anything else touch the text, or do you restrict access to a small set that you know will work in spite of the non-native text format. Or do you really only use the text under one OS and just occasionally do some editing on a different platform where you can get by with the wrong endings? -- Les Mikesell lesmikes...@gmail.com
Re: Compatible with Microsoft Office and Internet Explorer
On Tue, Jan 24, 2012 at 11:07 PM, Richard Cavell richardcav...@mail.com wrote: So, in the interests of keeping the Subversion handbook current and reliable, what is the present advice regarding svn:eol-style? If you are doing cross-platform work, you generally need to use native for text files or you will have to script your own conversions. But, never mix this with any other way of getting files between platforms, like moving a working copy on a usb drive between windows and linux, dual-booting with access to a common drive, or sharing a network-mounted copy. And the cygwin port of svn may think that unix style text is native even though it is on windows (I think that's an option somewhere deep inside of cygwin but I've forgotten - the point of cygwin is to make windows look like unix, so it might even make sense). -- Les Mikesell lesmikes...@gmail.com
Re: Compatible with Microsoft Office and Internet Explorer
I apologize in advance if the below reply is snarky, but I'm a little tired of this particular topic; it has been talked to death already long ago. On Jan 24, 2012, at 19:24, Nico Kadel-Garcia wrote: The big booby trap I notice with all Windows/Subversion use is the understandable desire to use native end-of-line characters to swap text files gracefully between Linux, Windows, and MacOS. Don't do that: it can bite you *VERY* hard if you access the same network filesystem, such as a CIFS share, from each of those operating systems or with CygWin on Windows. Nico, I know you have a strong opinion about the svn:eol-style property, specifically that it should never be used, and you love voicing this opinion in as many threads on this mailing list as possible, regardless of whether it is relevant to the thread or not. I'll respond yet again, in a different form that is perhaps more effective in explaining my views: There are several kinds of files you might have in your repository: 1. Binary files, such as images, sounds, videos, compiled programs, compressed archives, spreadsheets, presentations, some word processing documents, etc. Setting svn:eol-style to any value on these files would likely corrupt them, so svn:eol-style should not be set on these kinds of files. 2. Text files where you want some lines to have LF line endings and other lines to have CRLF line endings. I hope there is agreement that nobody ever wants these kinds of files, yet this is exactly the kind of file you will get if you do not set svn:eol-style, and you have several different people editing the files, on different platforms, using different editors. That was my actual experience at the last company I worked for. The specific problem editor in our case was UltraEdit on Windows, which happened to be the editor my company had paid for, so it was the one most of our developers were using. Unless you set four separate settings in its options window to four specific non-default values (which you had to wade through a hundred other options to find), it had very strange ideas about how line endings should be handled. (It preserved the existing line ending style for lines you did not edit, but used CRLF line endings for any lines you did edit.) Therefore, I recommend you always set the svn:eol-style property of text files to some value. What value? Read on. 3. Text files where you want line endings to always be LF regardless of platform. In this case, set svn:eol-style to LF. The Subversion client transforms the file's line endings to LF before commit, and when you check out, gives you a file with LF line endings. If you or your broken editor somehow transform some of the file's lines to CRLF line ending, the Subversion client* will prevent you from committing that broken text file back to the repository until you fix the broken line endings so that they are consistent. Hooray. Note that there is no problem if you or your editor convert the *entire* file to a different line ending style before committing; Subversion will seamlessly convert it back to the line ending style indicated in the svn:eol-style property. 4. Text files where you want line endings to always be CRLF regardless of platform. In this case, set svn:eol-style to CRLF. In the same spirit as (3) above, the Subversion client* will ensure the file in the repository has only CRLF line endings. 5. Text files where you want line endings to be CRLF if checked out with a native Windows client, and LF otherwise. In this case, set svn:eol-style to native. Subversion will store the file in the repository with LF line endings. When checking out on native Windows, it will convert the line endings from LF to CRLF, and on commit, will convert back to LF. On non-Windows systems (including cygwin, I believe), the files will be checked out and committed in their unconverted state using LF line endings. Yes, you will run into problems if you share a working copy between native Windows and non-Windows (including cygwin IIRC) environments. Rather than state that svn:eol-style should therefore never be used, or should never be set to native, you should instead stop sharing working copies. If you cannot give that up, then yes, in your specific unusual case, setting svn:eol-style to native might not be a good idea. Do not however condemn the use of svn:eol-style native for everyone, nor the use of svn:eol-style in general. I manage a repository of web site code. It contains HTML web pages, CSS stylesheets, JavaScript code, Markdown-formatted documentation. On my Mac I prefer these files to have LF line endings, because if I want to use UNIX command line tools on these files, they work best with LF line endings, and GUI editors on OS X default to LF line endings too. I assume Windows users would prefer them to have CRLF line endings, because that's what Notepad and probably other Windows editors work best with. Therefore these
Re: Compatible with Microsoft Office and Internet Explorer
Although I am mindful of the fact that at least one person is growing tired of this thread, The problem that you describe in your answer has nothing to do with Subversion. That is, the problems of transferring a text file from Mac to PC on a USB stick has always existed, independently of Subversion. Still, is it necessary to modify the SVN Handbook to make sure people don't make mistakes? Richard - Original Message - From: Les Mikesell Sent: 01/25/12 04:21 PM To: Richard Cavell Subject: Re: Compatible with Microsoft Office and Internet Explorer On Tue, Jan 24, 2012 at 11:07 PM, Richard Cavell richardcav...@mail.com wrote: So, in the interests of keeping the Subversion handbook current and reliable, what is the present advice regarding svn:eol-style? If you are doing cross-platform work, you generally need to use native for text files or you will have to script your own conversions. But, never mix this with any other way of getting files between platforms, like moving a working copy on a usb drive between windows and linux, dual-booting with access to a common drive, or sharing a network-mounted copy. And the cygwin port of svn may think that unix style text is native even though it is on windows (I think that's an option somewhere deep inside of cygwin but I've forgotten - the point of cygwin is to make windows look like unix, so it might even make sense). -- Les Mikesell lesmikes...@gmail.com
Re: Compatible with Microsoft Office and Internet Explorer
On Wed, Jan 25, 2012 at 12:31 AM, Richard Cavell richardcav...@mail.com wrote: Although I am mindful of the fact that at least one person is growing tired of this thread, The problem that you describe in your answer has nothing to do with Subversion. That is, the problems of transferring a text file from Mac to PC on a USB stick has always existed, independently of Subversion. Still, is it necessary to modify the SVN Handbook to make sure people don't make mistakes? The cygwin case could be surprising, and it is moderately common these days for people to share a network home directory across windows/linux/macs. It really isn't svn's problem that sharing a working copy in unexpected ways can confuse the 'native' concept, but it does come up on the list moderately frequently. Basically it is a bad idea to share a workspace at all, even with yourself under a different OS. And it is generally unnecessary since each platform can update its own copy easily enough. -- Les Mikesell lesmikes...@gmail.com
