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

Re: "--native-eol" to other commands than "cvs export"?

From: Raman Gupta <rocketraman_at_fastmail.fm>
Date: 2006-10-24 14:42:12 CEST

Johan Holmberg wrote:
> Hi!
>
> I wonder if it is possible to "fool" Subversion that the "native eol"
> convention is different than what is actually is. I have seen the
> --native-eol option to "svn export". But I would have wanted a similar
> option for "svn co", and that later subcommands operating on the working
> copy would also understand that I had done a "svn co" with the unusual
> setting of --native-eol.
>
> Background:
>
> I have a project where my working copy resides on a Linux disk. The
> files are accessed in two different ways:

I'd like this too but for a different use case: we do development on
windows and deployment on solaris. Normally, the build (and thus
checkout) is done on the same environment as the deployment and so
native line-endings are not a problem. However, for our test
environments, we regularly build on windows and deploy to Solaris for
testing. We use java and I've never had a problem with this
build/deploy dichotomy in several years, except for some problems
caused by line endings being incorrect due to the native setting.

Why don't I just switch to eol-style LF? Well, for the newbie
developers (and there are a lot of them in the java world) native is
easier. But I'd like the developers that understand the difference to
be able to force the style. Plus, the fact that changing the line
endings really messes up merges is a factor too.

So, if you decide to file an issue and need a buddy...

Cheers,
Raman

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 24 14:43:14 2006

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.