Please use "Reply To All" to reply also to the mailing list so others
can benefit from this discussion.
See my answer below.
On Dec 6, 2006, at 17:06, Peter Kennard wrote:
> At 17:53 12/6/2006, you wrote:
>
>> On Dec 6, 2006, at 16:05, Peter Kennard wrote:
>>
>>> I want to implement repository global mime-types so I don't get
>>> unexpected EOL problems across platforms.
>>>
>>> There is a huge list of suffi that are "text" and I would like to
>>> somehow enforce this automaticly on so when a user adds a .java
>>> (.cpp .c .h .hpp .txt ...) file (etc) it is registered as text with
>>> no explicit action required by the user.
>>>
>>> ie: there a way to specify this globally for an entire repository
>>> or recursive for an entire subtree?
>>>
>>> A search indicates this may not be possible (I can't believe this
>>> was overlooked in the initial design :)
>>>
>>> Is it?
>>>
>>> (The same also would be desirable for other properties like
>>> ignoring all ".o" files in a subtree by default :)
>>>
>>> Can it be implemented using any of the hook scripts (properly?)
>>
>> Line endings are not controlled by mime types, but instead by the
>> svn:eol-style property. Regardless of mime type, you can set the
>> svn:eol-style property to indicate that you would like Subversion to
>> force the line endings to LF, CR, CRLF, or whatever the native
>> encoding of the client is at checkout time. If you do not specify the
>> svn:eol-style property, no end of line conversion is done by
>> Subversion. This is the default, because it should be the default for
>> a revision control system to keep the files you give it, not mangle
>> them in some possibly irreversible way.
>>
>> You must not set the svn:eol-style property on binary file types such
>> as images or they will become corrupted.
>>
>> You can use the client-side Subversion config file to say that files
>> matching certain extensions should automatically receive certain
>> properties with certain values, such as svn:mime-type and svn:eol-
>> style. This feature is called auto-props (automatic properties) and
>> is described in the book at http://svnbook.org
>>
>> This is a client-side thing, not a server-side thing. If you want to
>> enforce this kind of thing at the server side, the recommended thing
>> to do is to install a pre-commit hook which rejects the commit of any
>> items that do not have the properties you require.
>
> Is there any way to have the client side configuration updated
> maintained / subset of overridden for a particular checked out
> subtree on the clinet?
>
> ie: so the client user does not think about it, installs svn (or
> tortoise svn) checks out the code and it just works as expected :)
> (of course IMHO any parser that pays attention to whitespace other
> than that it is whitespace is cracked, but I'm afraid things like
> Perl barf mightily :|
>
> That is, if eol style for a .xxx file as desired in the repository
> is (unix) but each developer potentially has a native type which a
> client should be aware of, and should covert to, (the local
> convention for the working copy) but when stored in the repository
> there is one proper standard. and as I said they just check it out,
> modify, compile, and commit.
>
> That of course is the desire.
Much of what you've written is confusing to me, but I've already
explained to you everything that Subversion offers. Auto-props are a
client-side feature only; they cannot be implemented at the server
side. If for your repository you want auto-props to be a requirement,
then you must install a pre-commit hook that prevents people from
committing things that do not match your policies. In the error
message that you print, you can even direct people to a web site or
other resource where they can find a Subversion config file that's
already set up properly for your situation, that they can simply
install into their client to avoid the problem in the future.
If you set svn:eol-style, Subversion coerces the line endings to LF
(always, regardless of what you set the property to) when it stores
the files in the repository. When you check out, depending on the
setting of svn:eol-style and your client OS, Subversion converts the
line endings of the files as it writes them into the working copy.
For example: you add a file to the repository and set svn:eol-style
for this file to CRLF. Subversion stores the file in the repository
with LF line endings. When you check out this file (to any OS),
Subversion writes the file to the working copy with CRLF line endings.
Example 2: you add a file but set svn:eol-style to native. Subversion
stores the file with LF line endings in the repository. If you check
out to Windows, the file arrives with CRLF line endings. If you check
out to Mac OS X, Linux, Unix, or pretty much any other OS, you get LF
line endings.
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Dec 7 04:53:15 2006