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

Re: MIME types extension matching is case-sensitive

From: Ed <SVN_at_0x1b.com>
Date: Tue, 2 Jun 2009 12:55:01 -0700

On Tue, Jun 2, 2009 at 3:19 AM, Bolstridge, Andrew
<andy.bolstridge_at_intergraph.com> wrote:
>> -----Original Message-----
>> From: ed.0x1b_at_gmail.com [mailto:ed.0x1b_at_gmail.com] On Behalf Of Ed
>> Sent: Tuesday, June 02, 2009 10:49 AM
>> To: Bolstridge, Andrew
>> Cc: users_at_subversion.tigris.org
>> Subject: Re: MIME types extension matching is case-sensitive
> [snip]
>> Are there any other parts of Unicode space you want folded?
>> diacritical marks onto greeks maybe?
>> pardon the snark - I haven't tried detox for mime-types, but for file
>> names it really works when I get stuff from people running your kind
>> of OS, set it up as a pre-commit hook to keep the repo consistent. It
>> has a powerful rule making system -
>> http://sourceforge.net/projects/detox/
> Perhaps Greek users would :)
> Perhaps I'm showing my naiveté of foreign languages here but I imagine only Windows filesystem casing rules would be relevant as files get their case changed by things like visual studio.
> I've just had to remotely debug why one of my users was received the old MKACTIVITY denied error (serves me right for posting a criticism of case-sensitivity to the mailing list, it got its revenge not half an hour later :( ) He had the files correctly cased, but not the repo name in the URL. It allowed him to checkout, but not checkin. Maybe that's a tortoise issue and not SVN, but still... it's annoying - especially where the error message is not clear, and the issue was not one of case-insensitive filenames.

yes, the IDEs do have a mind of there own - and I'm afraid detox is
less of a help in any environment that uses CamelCase.

From a Subversion design perspective, let me relay some of my
suspicions and maybe a real developer will chime in. I think that
Subversion sees all system discontinuities (case-sensitivities, line
terminations and even mime-type handling) as something of a
distraction from it's version management role, breaking a closely held
principle that the SVN server does not touch the code in the repo. And
then the camel stuck it's nose under the tent: Line terminations were
just too obvious a problem, and a relatively easy fix in a
text-or-blob world, so it snuck into the server, while other
accommodations were relegated to the external pre-commit check & block
world. The argument being that managing the spelling of a project's
files isn't really SVN's role, and the system with the highest degree
of discretion (most case discerning) will set the standard - which has
been, no surprise, the development environment for many Subversion

Mime-types being managed within the server also touches on a handy
trick that SVN has got a lot of mileage from. Subversion sees our
files as either a blob or text for much of it's core functions. Diff
touches this structure and is an area of growing er... desires. The
ability to Diff text, inherent in Subversion's design, is being asked
to expand to diffing formatted text files. While this will complicate
the code a great deal if Subversion is to run diffs on various
mime-types, it also poses the question as to whether the trick that
Subversion worked with text is even possible with formatted
texts/mime-types. I think that Subversion will not be able to handle
case insensitivity at it's core until the question of formatted texts
is understood and the developers have a way to work that trick again,
all the way into the basic core of Subversion.

or I could be completely wrong :) but I think the place to manage
your problem is at the pre-commit hook stage, sorry - tough place to
be running spell check off your data dictionary.


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-02 21:55:59 CEST

This is an archived mail posted to the Subversion Users mailing list.