Paul Lussier wrote:
>In a message dated: Wed, 05 Mar 2003 00:05:10 +0100
>=?UTF-8?B?QnJhbmtvIMSMaWJlag==?= said:
>
>
>>*however*
>>
>>If we make this a completely client-side feature, different clients will
>>behave differently when adding new files to the same repository. Ouch,
>>eek and yikes.
>>
>>
>
>Well, yeah, but would they necessarilly act differently upon the same
>files being committed to the same repository?
>
I *hope* not, at least for the most common types. But I've seen so many
cases of contents tagged with an invalid or unregistered mime type...
>If so, then I echo your 'Ouch, eek, and yikes!'.
>
Yeah.
Well, given that one can always fix the property retroactively without
having to check out a working copy (svn propset URL, remember) and that
the server doesn't give a bent farthing about the mime type, let's see
what can be done clent-side only.
>>So I think this sort of mime type configuration should be
>>a feature of the repository, with the clients just using the
>>configuration from the repo. We've talked before about server-side
>>configuration for clients, and haven't come up with a sane design, yet.
>>
>>
>
>But wouldn't having this as a repo feature cause a performance hit?
>
Depends on the design, doesn't it? :-)
>What about a server-dictated config for the repo located on the
>client? In otherwords, another file in the .svn/ dir?
>The file would/could be managed on the server, and read-only on the
>client. The client can use this 'map' to determine mime-types of
>new files added based on 'magic numbers' contained in the server-side
>config file. Though, that is rather like re-inventing the wheel if
>the client has a native ability to determine mime-types.
>
>Hmmm, this is a dilemma :)
>
>
See, now you know why we don't have a design for this yet.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 6 13:47:23 2003