>>>On Mon, 01 Sep 2003 11:49:44 +0200
>>>Jan Evert van Grootheest <j.grootheest@euronext.nl> wrote:
>>>>
>>>>I've just read the svn book on EOL settings. Here's a problem I can't
>>>>seem to figure out how to solve...
>>>>We develop for Linux, so we also use svn on Linux.
>>>>Some people simply prefer MS Visual Studio to develop, so we use Samba
>>>>to export from Linux to the (NT) desktop where Studio is available.
>>>>
>>>>Here's the problem: since svn is used on Linux, it uses just LFs for
>>>>EOL.
No - Subversion doesn't choose an EOL style, it just preserves the file's existing EOL style unless you tell it to change it.
>>>> For C(pp) and include files, this is fine and studio works well
>>>>with it. However, for the studio project and workspace files this is not
>>>>fine. Studio cannot read its own project and workspace files that were
>>>>extracted from svn (on Linux). Once these files are converted to CRLF
>>>>EOL, studio accepts them again.
Timothee Besset wrote:
> Note that doing a direct checkout on win32 won't fix your problem.
> svn
> currently lives in total absurdity regarding treatment of eols, so you
Hold on! If that is true, there should be an issue about making the behaviour less absurd. Are you making a fair assessment of the situation?
> will still have to set the props on .dsp/.dsw to have them with the right
> formatting.
Not necessarily. By default, Subversion doen't change the files at all, so if those files have the correct EOL style for Windows (CR-LF) originally then they will still have the correct EOL style (CR-LF) when Subversion checks them out, regardless of which platform Subversion is running on.
> The *right* way of things IMO would be to have svn use the native eol of
> the platform for all text files.
"Right" for your environment ... see below.
> This *used* to be the case, and it was
> changed to not modify anything and carry screwed up formatting across
> platforms
Exactly. Subversion by default carries a faithful copy of the file from one platform to another. If your editors "screw up" the formatting, then you can ask Subversion to help you out by setting "svn:eol" to "native" or another setting.
This is much safer than Subversion defaulting to a mode which modifies the file, because not every file
that looks like text can be converted from one EOL style to another and still work. For instance, someone mentioned that PDF files can be pure ASCII, but also contain byte-count indexes which would be invalid if CR-LF were replaced with just LF.
> (specially bad for guys like us who do OSX - Linux - win32 .. we
> have all 3 kinds of eol). But since I'm pretty much the only one who would
> want it that way..
What you want isn't unreasonable. You want to say something like "All of MY files should have Native EOL style." I would support a patch that provides a convenient way of controlling the default EOL style.
- Julian
> On Mon, 01 Sep 2003 12:03:31 +0200
> Jan Evert van Grootheest <j.grootheest@euronext.nl> wrote:
>
>>That's because we develop for Linux and that's where we compile/test/...
>>
>>Hmm, foolish me that I didn't even think about that! Too much locked
>>into SourceSafe I guess, where it can only be set per instance of VSS ))-:
>>
>>
>>Timothee Besset wrote:
>>
>>>You need to set the svn:eol property on the .dsp / .dsw etc. files so that
>>>they are always forced to CRLF format.
>>>
>>>On a side note, I think it's really bad to do samba exports of files with
>>>unix format to windows machines. Why not use a win32 svn client and
>>>checkout the code there? (Note that if you do that, the eol issues can get
>>>even more annoying .. so maybe you're right after all)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 1 13:25:50 2003