Re: CaSe insensetive OS not handled well

On Mon, 2005-08-22 at 18:30 +0200, A.T.Hofkamp wrote:
> If 3 is trusted, then the only problem is to map names from 2 to names from 1
> or 3, which can be done in the way Flex suggested in his answer to my email
> (posted at this list 19/08/05 19:10).
> If 3 cannot be trusted, then an svn client needs its own subroutine to
> normalize files (otherwise there is no trusted source for new files).
> This can take the form of a regular expression match/replace algorithm, for
> example a configuration file like
>
> gnumakefile = GNUmakefile
> *.c = *.c

Did you really just map *.c = *.c in your above example? Because that
would be wrong IMO. Imagine ( main.c = function.c ).

Although I know what you are trying to suggest: ( main.c = Main.c ) that
is not what is implied by the kleene star above.

Not to be rude, but SVN allows you to reject mixed case commits with a
hook script, but it will _never_ modify the transactions you create for
commits.

That is the way I prefer it.
The tool should not modify a commit, ever. No matter how trivial it may
be. This is a more reliable implementation, but by no means robust -
which is the motivation for hacks and fixes generated by poor
development tools.

I prefer reliable over robust in this case because subversion is very
important as a revision control program. It should not interpret what a
user _might_ have meant in a commit transaction.

In my humble opinion "transaction munging" leads down a long dark path
which may end up at repository corruption or non-deterministic commits.

This topic is often discussed, please read the mail {user,dev} archives
for more case insensitive discussions.

Cheers,
Chris

-- 
Wireless Group
McMaster University
summer
13:35:25 up 31 days, 23:28, 4 users, load average: 0.09, 0.11, 0.14
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org