Re: eol-style native

On Wed, Sep 24, 2008 at 5:28 PM, Steve Whitson <steven.whitson_at_gmail.com> wrote:
> 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.

Have you looked at svn:eol-style=share?

That keeps the line endings in the repository as Unix LF, but changes
them in your working copy depending upon the platform you use. On
Unix, they'll be LF, on Windows, they'll be CRLF.

--
David Weintraub
qazwart_at_gmail.com
> 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.
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org