Compatible with Microsoft Office and Internet Explorer

[ANTOINE-PRAVEEN-JANVIER Joseph -EXT]

 

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

 

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.

[Waseem Shahzad]

From: ANTOINE-PRAVEEN-JANVIER Joseph -EXT [mailto:joseph.antoine-pr...@alstom.com]
Sent: Tuesday, January 24, 2012 5:07 AM
To: us...@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

 

 

[Thorsten Schöning]

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....@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

[Nico Kadel-Garcia]

On Tue, Jan 24, 2012 at 5:06 AM, ANTOINE-PRAVEEN-JANVIER Joseph -EXT <joseph.antoine-pr...@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.

[Richard Cavell]

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

[Nico Kadel-Garcia]

On Tue, Jan 24, 2012 at 8:44 PM, Richard Cavell <richar...@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....

[Les Mikesell]

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 <richar...@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
lesmi...@gmail.com

[Nico Kadel-Garcia]

On Tue, Jan 24, 2012 at 9:38 PM, Les Mikesell <lesmi...@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 <richar...@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.

[Richard Cavell]

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 <lesmi...@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 <richar...@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.

 

[Les Mikesell]

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
lesmi...@gmail.com

[Les Mikesell]

On Tue, Jan 24, 2012 at 11:07 PM, Richard Cavell <richar...@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
lesmi...@gmail.com

[Ryan Schmidt]

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 files all have svn:eol-style set to native. Anybody checking out the repository will get text files with a line ending style appropriate to the environment they checked out to, and everybody is happy.

* The caveat is that it is the Subversion *client* that performs the line ending translation and verification; last I checked, the server does not verify that the client has submitted data that conforms to the file's stated svn:eol-style. It is therefore possible for a broken Subversion client to commit the wrong line endings. An example of a broken Subversion client is git-svn. You can work around this by writing a pre-commit hook. IIRC last time this was brought up somebody said the server should be fixed to detect this itself; I don't know if this has happened.

[Richard Cavell]

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 <richar...@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 
      lesmi...@gmail.com

 

[Les Mikesell]

On Wed, Jan 25, 2012 at 12:31 AM, Richard Cavell <richar...@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
lesmi...@gmail.com

[Johan Corveleyn]

On Wed, Jan 25, 2012 at 7:26 AM, Ryan Schmidt
<subversi...@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 users would prefer them to have CRLF line endings, because that's what Notepad and probably other Windows editors work best with. Therefore these files all have svn:eol-style set to native. Anybody checking out the repository will get text files with a line ending style appropriate to the environment they checked out to, and everybody is happy.
>

Nice summary, thanks.

> * The caveat is that it is the Subversion *client* that performs the line ending translation and verification; last I checked, the server does not verify that the client has submitted data that conforms to the file's stated svn:eol-style. It is therefore possible for a broken Subversion client to commit the wrong line endings. An example of a broken Subversion client is git-svn. You can work around this by writing a pre-commit hook. IIRC last time this was brought up somebody said the server should be fixed to detect this itself; I don't know if this has happened.
>

No, this has not been addressed yet. There is a feature request in the
issue tracker:

http://subversion.tigris.org/issues/show_bug.cgi?id=4065 (server
should enforce LF normalization for svn:eol-style=native files)

but I don't think anyone is actively working on it.

BTW, if anything should be done to the documentation, maybe simply a
warning that svn:eol-style=native should not be used when a working
copy is shared between different platforms (because of the changing
definition of what "native" means).

--
Johan

[Thorsten Schöning]

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.

[Giulio Troccoli]

Thanks Ryan. I've been using and manage Subversion for many year and the
exact way svn:eol-style worked has always somehow eluded me. Now it's
much more clear. I think I will print this email and keep it with the
rest of my notes.

Giulio

[David Chapman]

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 dcch...@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com

[Les Mikesell]

2012/1/25 Thorsten Schöning <tscho...@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
lesmi...@gmail.com