[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: converting from SVN to CVS

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: Wed, 28 Jan 2009 17:55:38 +0100

On Wed, Jan 28, 2009 at 2:54 PM, Spiro Trikaliotis
<usenet-200901_at_spiro.trikaliotis.net> wrote:
> Hello,
>
> Erik Huelsmann wrote:
>>> The problem with Cygwin is that there is not one "correct" EOL style,
>>> but two: Cygwin supported LF and CR/LF - and it even supports mixed
>>> configurations, in which some paths are LF, and some are CR/LF. libapr
>>> handles this case statically - it always assumes LF: This is wrong for
>>> many installations.
>>>
>>> The easiest correct way: Open the file in text mode and believe the
>>> runtime of Cygwin that it determines the correct style. Unfortunately,
>>> SVN does not believe the runtime, but wants to handle it itself - which
>>> is plain wrong, and a big bug.
>>>
>>> CVS does this correctly.
>>
>> I'm sorry, but this is NOT handled by the APR libraries (but by the
>> Subversion ones);
>
> Subversion asks libapr for the native line ending on the system.
> libapr's answer is wrong on many systems, including mine, because I have
> set up cygwin to use Windows line endings.
>
> I do not know what Subversion does around this call to libapr. Anyway,
> patching libapr to return CR/LF somehow "fixes" this problem in case you
> do not have a mixed installation of Cygwin (some mounts LF, some paths
> CR/LF).
>
> Thus, from an end-users point of view, libapr's answer is wrong, *or*
> Subversions handling of it is wrong. Either way, the resulting
> Subversion binary is wrong, too.
>
>> even more, Cygwin presents itself as Unix at build
>> time, which means this is NOT a bug in Subversion.
>
> It presents itself as Unix? How do you determine if something presents
> itself as Unix or not?
>
>> Moreover, CVS
>> doesn't handle this correctly: it doesn't handle it at all;
>
> It *does* handle it correctly by opening the file in text mode. That's
> the best solution to it: Trust the OS/run time that it knows its system
> best.
>
> Subversion does not trust the OS, but believes to know better - which
> sometimes results in catastrophic results.

Cygwin is not an OS. It will never be an OS. Cygwin is an ugly
workaround for problems people are having with their OS. To adjust
Subversion's behaviour would be stacking troubles onto troubles.
Cygwin is the *only* environment which has issues with our handling of
eols, which - given the number of supported platforms - should tell
you something.

Also: using Subversion on Cygwin (the cygwin version) is an insult to
the amount of trouble the developers went through to bring to you a
native Windows version of the tool.

BTW: If you have issues with eol handling: just disable it. Subversion
will leave your files alone and you'll need to configure your editor
to handle the eols correctly. From personal experience: that works
great.

Bye,

Erik.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1063661

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-01-28 17:56:42 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.