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

Re: eol-style native

From: Steve Whitson <steven.whitson_at_gmail.com>
Date: Wed, 24 Sep 2008 16:28:49 -0500

Thanks Ryan for the response.

I see now that the properties I received were the defaults in the client
I used (smartsvn defaults).

I have many files that are in xml format, but should be treated as
binary (application/octet-stream as their mime-type). Also, most of our
current audience viewing our documents, text files, etc, are on
ms-windows, but that may change. So, for now readable text files need
to remain CRLF eol-style. Other text files are best saved with LF
eol-style. Yes, this is deducable through extensions (99.9% of the
time). I have setup the autoprops on my windows config (for tortoise
client and command line svn), and will do the same for my command-line
unix config, and will have to figure out how to get this into smartsvn
too (should be easy). Now for all my users :). I guess I'll have to
type up usage instructions, and try to get consenses from our diverse
multi-target projects. Leaving things as they were produced by the
developers, or as they were produced by their tools is usually the
safest bet from my experience... although customers typically like
things (readable text files) in the format of the platform they use.

One other issue here is that in order to maintain softlinks I have to
keep the master working (reference) copies on unix, which leads to
problems when auto-props is turned on and eol-style is native...
especially when expectation is that the eol doesn' t change between
platforms. For some tools/languages/scripts that's not an issue, for
others it is.

A work in progress,
    -Steve

Ryan Schmidt wrote:
> On Sep 24, 2008, at 09:24, Steve Whitson wrote:
>
>> Is there a way I can turn off the automatic setting of the property
>> svn:eol-style native?
>
> It is off by default. To turn it on for, say, all .txt files, you add
> this to your client's Subversion config file:
>
> *.txt = svn:eol-style=native
>
> So, if you want Subversion to not automatically add that property to
> those files, simply remove that line from your config file again.
>
>> I would prefer to turn this feature off per repository. I have some
>> repositories that may benefit from this feature and others where it
>> will just get in the way. If not per-repository, is it possible
>> server wide? Doing this per-user (client) config sounds awful
>> cumbersome and problematic in my environment.
>
> Automatic properties are a client-side setting only.
>
> You can write a pre-commit hook for your repository which prevents
> commits which do not meet your requirements. For example, for one
> repository, you can require that all .txt files have this property
> set, and for another repository, you can require that it not be set,
> if that's what you want. Committers are responsible for adding or not
> adding the property, as needed.
>
> If you look at "svn help commit" you'll see a "--config-dir" argument.
> Users can set up a config directory per repository, and whenever they
> commit to a particular repository, they can use the --config-dir
> argument to specify the config dir for that repository. That way they
> can set up different auto-props rules for different repositories. I
> admit that's not as convenient as Subversion automatically knowing
> what rules to use for what repository, but it is the only thing
> Subversion offers at this point.
>
>> While reviewing the per-client choice, I've looked at the client
>> [auto-props] section in a config file, but I don't see how to turn of
>> such a feature (eol-style =native), only how to add it.
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-24 23:29:14 CEST

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.