Friday, August 19, 2005, 7:54:45 PM, you wrote:
> Question I've always wondered, does anyone ever really name two different
> files with the same name but different case? What's the scenario?
:)
> And how could this possibly be handled in a mixed OS environment? If a
> development group expects any work to be done on 'insensitive' platforms,
> does it seem likely they'll choose conflicting names?
No, he talked about other conflicts, similar to the thing below.
> How about a repository-wide setting to deterimine whether names are case
> sensitive or insensitive?
Better be on a client side, since it'll allow mixed clients
I'm posting a conversation with A.T.Hofkamp about the problem and my
suggestion on it since the discussion touches that topic too.
=============================== A.T.Hofkamp QUESTION ==================================
> Hello,
> I have been following the discussion at the mailing list.
> I am not involved in svn development nor do I have the case-sensitivity
> problem, I am just trying to find a proper answer for the problem.
> Maybe you could give some feedback on my thoughts:
> Flex wrote:
>> Agreed. Second easy solution - an universal "comparing" function which
>> returns either case sensitive or insensitive compare (just uses one or
>> another function) based on the flag.
>> "What flag?" - just some flag that has to be put on the command line in
>> case of client wants case insensitive compare, i.e.
>> svn -C ....
> This may seem to be a solution, but I think it isn't.
> (I am fairly new with the topic, so please try to find the weak point in my
> reasoning...)
> The problem is not in the case-insensitive compare, it lies in the decision
> what names should be used in the central repository, and consistency of those
> names (I think so, at least).
> For the remainder of the discussion:
> case sensitive = CS
> non case sensitive = NCS
> Suppose a NCS machine creates a file xy.c . Since it is a NCS machine, the
> case of all letters may be different, ie there are 8 possible file-names if
> looking from a CS perspective.
> Which one of those 8 should be stored in the repository?
> Now assuming the convention that *.c at a CS machine is a C file, and *.C is a
> C++ file, you typically don't want one half of the files with .c and the other
> half with .C extensions in your repository, because it would break a build at
> a CS machine.
> Also, you really want to have a consistent name in the repository, ie once you
> have a file abc, it should stay abc, and not suddenly be renamed to abC just
> because a NCS machine commits that filename.
> (if that would be allowed, you'd get CS problems in the repository, and they
> get shifted to CS machines (although I am not sure whether they are not there
> already)).
> What do you think?
> Albert
==================================== MY REPLY ======================================
Good point :)
I think in a system that is supposed to handle both CS & NCS systems,
the CS should have priority.
Several cases:
1. I create a new file from the NCS system:
svn up \\path\to\file.C -NCS
it has 2 ways to be stored - either all lowercase (file.c) or the case
it is at now (file.C). I prefer the first one but it doesn't really
matter. Let's take the first case and it gets stored as file.c in the
repository.
If I put it again with changed case from the NCS system with -NCS option:
svn up \\path\to\FILE.C -NCS
The idea is svn to not assume this is a different file, but to take
the stored one (file.c) and update it, keeping the case the same.
Since NCS system does not care about the file case, the case in the
repository takes priority and the file will be checked out how it was
written in no matter what case u used to update it.
2. I create a new file fron CS system
svn up \\path\to\FiLe.C
Alright, then a NCS client gets FiLe.C when checking out and no matter
if it tries to up it as a file.c, the case of the repository is
considered leading and the file stays as FiLe.C
Again, it's a matter of one compare somewhere or one compare function
change.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 19 19:14:54 2005