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

Re: CaSe insensetive OS not handled well

From: Vincent Starre <vstarre_at_comcast.net>
Date: 2005-08-23 13:44:42 CEST

I really dont see what all the discussion is about, about should
MyFile.c be converted into myfile.c. It seems simple in my mind:
to a case-insensitive, they are the same file, so unless someone has
specifically said svn mv, there is no reason to do anything "special":
simply compare them in a case-insensitive manner and commit MyFile.c as
it appears in the repos: myfile.c (or MYFILE.c, or whatever)
if someone has said "svn mv", rename the file. There is no excuse for
adding a new file or renaming a file without specific mv or add
commands. There is no ability for a case-insensitive OS to treat them as
seperate files, so there should be no attempt to support such.
If the filesystem thinks they're the same file, make them the same file.
It's not like a filesystem which can't support two files with "the
same name" is going to have two files with "the same name" anyway.

I am opposed the the term "mung" in this situation. There is no changing
of any data as far as a case-insensitive OS is concerned. There
is no need. If it looks like MyFile.c in the repos, it will be committed
as MyFile.c. The WC will stay the same, the repos will stay the same.
There is no "mung". If someone wants to actually change the case of the
filename, they should svn mv, just like they would in any other

I really dont see what all the discussion is about anymore.

as for svn:filename, I considered that breifly, then shot myself. I
expect to bleed to death soon. :)

A.T.Hofkamp wrote:

> Flex wrote:
>> Can svn commit file.C and file.c a the same time, same folder now? And
>> does anyone uses that in fact? If not, can it be "disabled" so basicly
>> imitates this pre-commit hook?
> I would expect, yes it can be done.
> Disabling is not an option I think.
> You want to have consistent filenames all over the project, which need
> not be 'all lowercase' (that is just one view of 'consistent').
>> Of course the pre-commit hook can be used too (when -NCS is not
>> specified) to guard against mistakes, just as it does it now, but
>> better if the whole system handles that.
> The trouble with pre-commit hooks imho is that you are doing damage
> control rather than prevent damage from happening.
> For a long term solution I think that is not the right direction.
> The same is also true for the -ncs flag to some extent, do you really
> want to forever have to specify the -ncs option?
>>> It also involves an understanding of your platform and your file system
>>> for the client _and_ server machine you are working with.
>>> I would be more open to a new property called "svn:case-insensitive"
>>> which acted like the "svn:executable" property. If set the client
>>> performs a well defined, deterministic action on the file/directory.
>>> This action could be munging all the file names to lower case, upper
>>> case or something else.
>> There is one problem with this approach - the properties gets stored
>> and distributed so there is a nice chance someone with CS system to
>> checkout folder that has this property set from an NCS system.
> and of course not all clients use the same action, and we have chaos...
> In other words, the 'action' needs to be consistent over all machine
> in the project, which in turn makes it possible to do this action at
> the moment of adding the file only, which in turn means the
> svn:case-insensitive flag is not needed.
> (maybe it is just me, but I cannot really imagine how a *file* can be
> case insensitive).
> I was thinking about a svn:filename tag, which is very nice too, we
> don't need svn mv anymore then...(and we can have unicode filenames
> for free! Finally, I can write my "&#x25c7;" :-) )
> Who needs names at the file system.... :-)
> Albert
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 23 13:47:15 2005

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.